Tuesday, June 07, 2005

Via ongoing, and Bosworth, a comment from Bill which echoes my previous post about mobile code:

Adam, I'd be less interested in XML v Javascript, than Declaration v Behaviour.

This is starting to sound like what Bill Joy said a few years back about XML - at some point you need to send behaviour around, declarations aren't enough. That, for exactly same reason we end up putting scripting hooks in all our declarative languages.

Sending Javascript notation for client eval will work. Eventually you will want to sandbox that behaviour off for security reasons (and limit the effect of bugs). At that point you're within spitting distance of Java 1.0 and its security model, which was designed with running remote code in mind - a chroot jail for objects.

Round and round we go!

So, now we've come full circle maybe it's worth talking about a Jini browser. It's an idead I've had for ages, but essentially it echoes a web browser except that it's Swing (probably). And I don't mean Swing HTML controls, but fat client GUI talking whatever you want off that back due to Jeri etc. You want to administer a switch in the darkest recess of the network? Then open it's GUI.

Now I'm sure a pure fat client approach is overkill and HTML is fine for many (if not most, I'm a thin client fan), but it'll be interesting to see if the Ecmascript world starts evolving most advanced security models to cope.

This brings me to a bug bear (sp?) of mine. Yes, Java has a nice security model (ok nice maybe isn't the right word, but powerful at least) and applets can and most do bhave within it. But WHY do almost all WebStart demo's request full security access just to demo some fat client behaviour? This makes the security guarantees pointless. Lazyweb, please make people fix demos so no extra priviledge is needed. Sun please make it easier to do this. (I know there are a few bits and pieces out there - a tool from Kevin Jones at DevelopMentor springs to mind). Mozilla.org/Sun, please fix the JVM /browser integration/applet capabilities (eg allow an applet to request simply (with no other privs) to live outside the page lifecycle (either tied to the browser or even longer). This stuff needs to be easier. Maybe a Groovy browser / rhino plugin could help blur some lines... dunno.

Comments: Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?