The present state of affairs for offline web applications is not satisfying, so thank you for hosting a forum to discuss the future. I’m interested in attending because I’m involved in the development of the relevant capabilities in Google Chrome.
The last few years have seen the specification of a handful of offline enabling technologies along with nascent implementations from different browser vendors. That set of enabling technologies include, LocalStorage, WebSQLDatabase, WebIndexedDatabase, WebFileSystem, WebWorkers, and ApplicationCache. Support for these is fragmented and where implementations do exist, critical components are not mature or stable enough to rely on heavily.
However, even if those technologies were fully implemented and fully baked, the resulting system would still not be satisfying.
A full implementation of the suite of technologies do make it marginally possible to construct a separate offline web application. A limiting factor is bootstrapping from arbitrary urls, the static resource cache and limited mapping of request urls to static resources provided by the ApplicationCache in particular is not satisfying. A more dynamic mapping, ideally under direct programmatic control of application logic, could remove that limiting factor. Either extensions to the ApplicationCache or a separate mechanism to enable url request interception should be added to the mix. But beyond better bootstrapping...
A more fundamental problem is that the goal is not really offline web applications. Traditional web applications are designed assuming a working network connection. These new technologies promise to enable the creation of variants that can operate offline. The obvious problem with the separate variant approach is that there are two applications to write and maintain. For large and complex applications, that's not viable.
A better goal would be: write the application once, it works online and offline.
If the technologies designed to enable offline applications, could also be used to satisfy the fully online case, then we’d have something. The same application control flow could be used in either case. A different set of requirements for these enabling technologies flow from this line of thinking. Consider the install step, it would have to happen entirely transparently as an artifact of visiting the site. Consider the lifetime policy of any data put in a client-side database or filesystem, it becomes more a function of the lifetime of the user’s login to that application. Consider the privacy of client-side data when a user accesses an application using his credentials for that web application on somebody else’s device, it becomes desirable to encrypt that data accordingly.
It’s my hope that the future of Offline Web Applications is more aligned with the future of Web Applications without the connectivity qualifier.