RIA and Mozilla

With Longhorn, Microsoft are busy building a richer environment for delivering applications to the desktop. In the meantime some in the non-Microsoft world have been busy pushing the concept of Rich Internet Applications. Two of these (Laszlo System's presentation server and Macromedia's Flex) leverage the ubiquity of Flash. But the gamble that Microsoft is taking is that you really need to extend the browser. Microsoft need to deploy XAML compliant browsers to support their approach. In the same time-frame couldn't an open-source browser like Mozilla be extended to make it the preferred target for advanced RIA? Afterall it already contains functionality that has no equivalent in IE (e.g. XUL). And just how long will it be before there are more XAML capable browsers than Mozilla?

I don't want to tread on anybody's definition of what a RIA is - or how they compare to what Microsoft is planning to do - so let me just be clear about what I would like to see from a future Internet application as a user:

1. Easy deployment: I can access/invoke the application through a browser. A RIA may download/install software, ask for access to local resources etc. but the starting point is my everyday browsing experience. The more transparent it is, the better
2. A richer experience: this is probably more about removing some of the limitations that afflict pure web-based applications, rather than an absolute requirement for more 'richness'. Such limitations include;
   • a lack of responsiveness - some essentially trivial but uncommon validation tasks require a round-trip to the server,
   • difficulty in being able to dynamically update parts of a page,
   • a limited set of standard 'widgets' available to forms builders.
3. An uninterrupted experience: ideally I should be able to continue accessing the application through the browser from which it was originally invoked.
   
   and two 'nice to haves'...
4. Roaming personalisation: if the application supports some level of personalisation, then ideally it will move with me even when it is accessed from a different browser on a different continent.
5. Unfettered access: if the application deals with remote resources, then ideally it should be able to access them anywhere on the Internet and not be restricted to the source location of the application itself.

I feel a bit churlish writing this, I'm using the new Blogger web interface which has a 'Preview' function that works instantly and doesn't require a server round-trip!

I've been involved in some sizable web applications in my time. Although Laszlo and Macromedia offer to hide much of the plumbing and reduce my job to delivering LZX/MXML, I can't help but feel you cannot hide the browser/server connection. It has to be recognized for what it is. My preferred architecture probably borrows more from a desktop application. My version of an Internet application would be a browser download that:

• takes responsibility for handling 'session' state,
• interacts with the browser via events directed to it from the page, and an ability to inspect/manipulate the content of the page,
• talks to remote web services.

Standards exist for much of this (DOM, update via DHTML, communication with web services via SOAP), the big problem is downloading an application into the browser. Essentially this is a downloadable application that uses a browser to present its user-interface rather than building its own. Compared with other browser downloads, the distinction is that it runs in the browser itself, not in an individual page. It's job is not to do simple things like validate user-input before passing control back to a server. It's job is to be responsible for the application as a whole, coordinating the various steps in the process, calling upon web services as and when they are required. These services can themselves be simplified; for example they may no longer need to handle state or presentation details, making them more usable across a range of applications.

I must now declare myself a frustrated Java developer. I've managed to prototype some of these ideas but there has always been a piece missing, a technical hurdle that is way too high. Java has an evolving story about talking to remote web services, and it just gets better. Java Web Start, IMHO, does a good job of downloading application code but then more or less forces you to use Swing for the user-interface. This would be better if you could include components that can handle HTML. However a better solution would be to have Java running inside the browser. I've built pages that dynamically fetch new data to update parts of themselves by calling upon the services of a featureless Java applet running in a separate frame, but the applet is sandboxed and cannot talk to the whole web. I might have been tempted to use James Gosling's JNN more (a minimal RSS reader with some nice layout and drag-and-drop features) if I didn't have to manage both its window and the browser window that needs to accompany it.

Is it possible to build Internet applications this way? Does anybody else want to?