Offline Web Applications

So, apparently, the Achilles heel of Web Applications is being worked on. Mozilla has added DOM Storage (access to an SQLite database through JavaScript) to Firefox 2.

I won’t claim to have read the Web Applications 1.0 working draft (which proposes DOM Storage and other features) in its entirety. However, from what I got out of it, it doesn’t seem to go far enough. Web Apps will benefit from offline storage but they would also benefit from greater interaction/freedom with the host Operating System. Not as much freedom as a traditional Desktop App but a larger sandbox than current Web Apps operate in now. In a way, the user should be able to “Dock” a Web Application in order to expand the sandbox security model. Maybe this is just wishful thinking, but here are my thoughts on Dockable Web Applications.

Example User Flow

1. User visits a website using a web browser and tries out a web application
2. User sees an indication that the web application is “dockable”
3. User clicks on dockable indication and drags it to a docking area
   • Docking is, of course, optional and should never happen without a user initiating the event
   • Ideally, the docking indication is shown in the browsers interface and not the web page itself. This way, an OS/Browser combination that does not support docking will not indicate a docking ability.
   • A good UX for this action could be a visual representation of the web page being torn from the browser and consumed by the docking area
4. Application is docked
   • Becomes Accessible through Applications or Start Menu
   • Components indicated by manifest are downloaded and saved to computer
5. User launches Docked Web Application (DWA)
6. DWA opens but in the Dock (browser minus location bar, navigation, etc.)

How it might work

This is a bit tricky. A DWA would have to be designed with docking in mind. However, reuse of existing Web App resources like HTML, CSS, JavaScript, and Images should be a primary goal so that a DWA is not a complete rewrite of an existing Web App.

The Dock host environment can provide JavaScript with an API to additional features not found in a browser. This API could provide JavaScript with the ability to read and write to certain areas of the file system, access to an application specific local database (i.e. the Dock comes with a database program and each DWA can create a new database for itself), and perhaps image manipulation libraries. With the API, any existing JavaScript that makes XmlHttpRequests to fetch server-side data, can first method sniff for the Dock API, and if found, route the request locally instead.

With this in mind, a DWA must have another design change. HTML can not be personalized (rendered dynamically via sever-side technologies) since the DWA would have no server to generate it. Instead, a Web App would use HTML and CSS to provide the structure, style and sensible default content and JavaScript to make XmlHttpRequests which would then personalize it. When “docked”, this same app would then make API requests to the local file system or database and receive data (Strings, XML, JSON, etc.) back which would be parsed and dealt with just as if it came from a remote server.

Lastly, the DWA must provide some initialization scripts to set-up the local environment. These would be JavaScript that use the Dock’s API to save files to certain locations, create directories, and create necessary tables in the database if required.

With data saved locally, the DWA must eventually synchronize its content to the remote server. To accomplish this, the Dock should provide an API to send and receive updates to its local content when it detects it is online. The frequency at which it pings the remote server ought to be configurable by the DWA. Also, at configurable intervals, the Dock can check with the remote server and download any updates to its resources: HTML, CSS, JavaScript, Images, etc.

Additional Considerations:

• Where are passwords/usernames stored to allow the Dock to send and receive data and updates?
• What is the security model (should the DWA only be able to send and receive data with the source domain)?
• Is a shared image directory of icons required? - No, since the Web App version would not have access to them.
• Since it is possible to access a DWA and at the same use its online counterpart, how will conflicts in synchronization be resolved?
• What happens to XmlHttpRequests when a DWA has access to the Internet? Are requests still routed locally then synced or is this bypassed?

Steps to a Prototype

What is the simplest possible way a working prototype could be made?
Keep the problem small and don’t try to solve all the details. That being said, since the Mozilla foundation is providing some needed “Dock” features in the Firefox 2.0 release. Namely, it comes with DOM Storage and Storage and the ability to build other applications based on the XUL Runner framework.

The “Dock” environment could be built as a simple XUL application and provide a convenient API to SQLite. It can also, hopefully provide the ability to save files to the file system.

A simple Firefox extension could be created to act as the DWA notifier. It would simply scan the currently viewed Web page and indicate if the web application is also a DWA (nothing complicated, just meta-tag indicating yes or no in the HTML page).

Does this sound like lunacy? Is it already being developed?