« Web Apps' (Current) Advantages Over Fat Clients | Main | Safety-net for WebDAV dogfood »
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 July 22, 2005 1:03 PM
Comments
Interesting. The update model I think is the more important of the two. In say, .net, a windows forms app can use reflection to load an assembly via a URL string pointing to the dll on the web server, it is then cached locally so as long as the published version of the dll doesn't change, it doesn't have to be redownloaded. Something like that for xulrunner would definitely be ideal.
Question: could a new protocol help - for example a xul:// that would give you the same affect as what you described?
-woo
Posted by: Andrew Douglas at July 22, 2005 2:03 PM
http://wiki.mozilla.org/LocalStorage has some ideas for making Web apps run "more locally", in particular, offline.
Basically we'd add a couple of extra features for Web apps:
-- pinning pages in the cache so they're guaranteed to be available offline
-- local storage via some kind of "super cookies"
I think the biggest difference between Web apps and XULRunner/"local apps" is actually the trust model. The user does not need to trust a Web app beyond the functionality it provides. On the other hand the user must trust a "local app" completely. So I think in addition to XULrunner it's also useful to try to extend Web apps to have more "local app" features without changing the trust model.
Posted by: Robert O'Callahan at July 22, 2005 2:12 PM
Can I make my comments on German? ;-)
The one thing that puzzles me about remote apps is server security. Download once, and the user's risk to get malicious software depends on the status of that server at the time of that particular download. Update every now and then, and the user is at risk at each download that the particular server is compromised. Which, btw, make hacking such servers much more attractive.
Posted by: Axel Hecht at July 22, 2005 2:30 PM
There is still this security issue. What if the server serving our application is hacked? Will we infect thousands of users with viruses instantaneously? It isn't enough to sign the file containing the original application.ini, each file of the application needs to be signed. And even then you have a problem: what if the program developers suddently turn evil? A web app has limited privileges, it can't do you any harm. A standalone application is only updated when you request it, you can reject to upgrade if hear of problems with the next version. But what can you do with an application running with full privileges and updating itself automatically from the web? That's like giving away the keys to your appartment to somebody you don't know assuming that he will never use them.
Ok, Java Web Start is doing this thing already. But I think there is a lot of trust involved in installing an application like this.
Posted by: Wladimir Palant at July 22, 2005 2:43 PM
I love ponderings like this.
Posted by: Tsee at July 22, 2005 4:56 PM
Well, I apparently don't need to express my thoughts, because you seem to be reading them :)
On the topic of system apps vs web apps, there is a further point in web apps favour: flexibility for the user. A web app can (with a little effort) be made available on any (major) browser on any OS. More than that, the user can often be a /computer/ (e.g. a program can plug a search into almost any site, and read out the results with a little html-scraping). Further, people can write scripts to plugin to those pages/apps automatically (with scary insecure extensions like greasemonkey ;) ).
My point is, try to keep that flexibility. Make it easy to /extend/ web apps into system apps (when it makes sense). For example, most accounting system apps work great as web apps, except in some rare cases where you need extra capabilities --- like notification daemons, editing/reading local files and directories, communicating with other processes, etc. Obviously, you can just wrap some xul chrome around your web app, but that can get messy. But if tight system-web integration is easy (while keeping pure-web app compatibility), developers won't have to do almost any extra work to keep that flexibility for the user.
This ties back to your blog post. Ideally, someone goes to http://companyapp.com, and uses the web app version. Up the top somewhere prominent is a link to install the system app version. The install would work exactly as you describe, and then once the system app is running, would look identical to the web app, but be more capable and better integrated into the OS; it would also maintain exact sync with the web app's files --- the web developer would only need to maintain one tree, not a separate one for the system app, and another for the web app.
And perhaps, once installed of course, it would even be possible to run the system app with full capabilities from a Firefox browser tab.
ah, but one can dream :)
Posted by: voracity at July 23, 2005 7:40 AM
To put it from a user perspective in this, I love the idea, I would (as a user) like to be able to choose to "download all at once" and "check for updates" in an app which does this though, if at all possible (as I currently am on dialup)
And in situations where I use this "web-app" then I am offline, I want to use [x] feature which has not been cached yet off the web, Ooops I dont have it.
Or when [xyz] function (script) was needed, so checked for caching, ok...updated... later on that script is not needed, but another one (which has portions and calee's which use the initial one) updates, now I'm offline, and some other portion of the webapp, uses functions in the "up to date" script, which calls functions in the "not up to date script" all of a sudden I get JS errors, since I hadn't needed to update the "not up to date" script before, and I am offline, and its trying to use from cache.
Seems like a programming/logic nightmare in the end. But I like the concept, if you or someone are able to flesh out the logic of it, GREAT.
Posted by: Justin Wood (Callek) at July 24, 2005 12:22 AM
That sounds amazingly cool. I'm sure it's going to set off lots of peoples' security alarm bells (correctly or not) but it still sounds amazingly cool. How do you think this stacks up to the XAML + .NET offering?
Posted by: Andrew Smith at July 25, 2005 4:43 AM
Having got over the cool-factor now, some possible down-sides:
1. Incremental download will cause a delay when new windows are shown for the first time.
2. Developers will have to be careful about setting cache expiration, as they may end up with JS that mismatches their XUL. I suspect this is worse than in the HTML world as more processing is done client-side.
3. This model may break the use of mirror servers for to deploying your application.
However, all that said, I can see this being killer for small intranet based apps.
3.
Posted by: Andrew Smith at July 25, 2005 4:57 AM
Andrew, I agree completely that this would be ideal for an intranet-based application... but not just small apps! I work for an ERP software company whose flagship software encompasses over 1,100 discrete application screens. Being able to install the system at one central location with the ability for the sysadmin to place software updates in one place for incremental updates---! Nirvana.
Posted by: William Gammans at August 4, 2005 12:56 PM