« June 2005 | Main | August 2005 »
July 22, 2005
XULRunner-based Web Apps
In my last blog entry, I talked about blurring the lines between between web applications and fat client applications. One piece of my thinking here is that several important characteristic differences between today's web applications and XULRunner apps as they are currently conceived are the following:
| Download model | Update model | Process space | |
|---|---|---|---|
| XULRunner app | Explicit, all-at-once download and install | Explicit update by UI action | Own Process |
| Browser-based web app (remote HTML or XUL) | Implicit incremental download | Implicit update via reload or cache miss | In browser process |
A common reason that an application wants to be a XULRunner app rather than a web application is that it wants to live in its own process for one of a number of reasons. But I think many such apps would still prefer the incremental download and implicit update features of web apps for their location independence and ease of deployment advantages.
Instead of requiring a XULRunner app to be a zip file for local installation, imagine a world where the XULRunner app lives at whatever web page you like. You go to that web page with whatever browser you want, and it finds something of content type application/xulrunner, which is a signed jar file containing only the application.ini.
The jar file is handed off to a new XULRunner process. If the user gives permission to install (which should use equivalent UI to the extension installation UI, since this code will be running with the same privileges), a profile is created specifically for this application, very much like a Firefox or Thunderbird profile today. That profile has its own HTTP cache and component registry, and the necessary UI and components are downloaded as needed. The application.ini contains the information about the startup object and the components/extensions necessary for the most basic bootstrapping. XULRunner then automagically downloads the bootstrapping dependencies into the HTTP cache, installs any necessary components, and then launches the startup object. All application content is downloaded lazily and kept in the cache, which means that it can be updated in the same way that web apps are today.
I think this approximately provides an app model which has important advantages of both web applications and fat clients. It seems like it should be straightforward to flesh out the details to ensure that such apps could run well offline, and, even better, when intermittently connected.
I'd be interested in hearing thoughts on this little Gedankenexperiment...
Posted by dmose at 1:03 PM | Comments (10)
July 11, 2005
Web Apps' (Current) Advantages Over Fat Clients
I've been doing a bunch of thinking lately about how people use web applications, fat clients, and the blurring of the line between the two. In particular, I've been focussing on mail readers, in part because I work on one, and in part because it's an area where both web apps and fat clients have very significant market share. A big reason that web mail clients are so popular these days is that they provide a set of features that fat clients often overlook.
Notable ones include:
* automatic configuration - after you create or login to your account, no extra configuration is necessary to begin using it. No need to know what an SMTP or an IMAP server is, let alone which ones your ISP happens to need or what sort of authentication options have to be chosen.
* continuous, automatic incremental upgrading - much of the time when the app needs to be updated to a new version, it's just done on the server without even bothering to warn the user, since there's no preparation, reinstall or any other action necessary. Furthermore, since it's so cheap to deploy an update, that makes it much easier to incrementally implement and deploy new features rather than just having occasional major releases.
* config data location independence - if you've customized your preferences in any significant way, in a web app, those customizations are sticky: they are simply done. Whatever machine you access the app from, you never need to enter it again.
* accessible from any machine with a suitable web browser - there's no real install step necessary.
In order to continue to be competitive, it's my belief that fat clients need to do a significantly better job at providing the set of features listed above. My next blog entry will be about my suspicion that by adding a small set of things onto XULRunner, Mozilla-the-platform will be able to make it easy for fat clients to provide many of the key features in web applications that people have come to depend on.
Posted by dmose at 10:56 AM | Comments (1)
July 6, 2005
#maildev
For those who haven't heard about it yet, a bunch of folks who hack on mail/news in the form of Thunderbird, Seamonkey, or extensions have taken to hanging out in the #maildev channel on irc.mozilla.org. The intent is specifically to provide people with a place to discuss code/development related issues. So if this is code you're working on or are interested in working on (in the form of writing code, bug triage, documentation, etc.), feel free to join us. End-users seeking support are encouraged to visit #mozilla or #thunderbird.
Posted by dmose at 10:23 AM