[whatwg] HTML5 Offline Web Applications

[Philip Tucker]

I'd like to offer more justification for Michael Nordman's "scriptlet"
proposal.
We've spent the last year or so modifying an existing online application to
make it work offline. A secondary motivation was application speed. We used
Google Gears to enable this. Although we had some success, we also had
challenges. Here are some of the big ones:

   1. *Significant architecture change*. Our web pages are built on the
   server without much concern for separation of application logic and user
   data. User data is usually just "baked in" to the page. In captured/offline
   mode, we have to serve a generic page that can fill in user data via
   javascript. This required changing the online application in significant
   ways just to support offline functionality. And, it required forking the
   code in many places, leading to maintenance difficulties.
   2. *All-or-nothing captured mode*; i.e., once a URL is captured, it is
   always served from offline cache. This means if we encounter a bug in the
   offline app, it's not easy to fall back to the online app. We could serve
   the offline app off a different URL space, but that makes for harsh
   transitions between online and offline mode; e.g., on a flaky connection.
   3. *Single sign-on was hard*.

How I think Michael's proposal addresses these:

   1. Some applications have cleaner separation of app and user data than
   others, but one consistent point of clean separation common to all web apps
   is the HTTP layer, between client and server. Michael's proposal would allow
   applications a hook at precisely this point. Most client javascript could
   remain unchanged. XHR servlets would be replaced with client side
   scriptlets. Server-side templates could be fairly easily migrated to
   client-side counterparts that populate the template from a local data store.
   2. These scriptlets could also offer a failure mode that would fall
   through to the online app.
   3. We had to jump through all kinds of hoops to get single sign-on to
   work. We have to have 2 separate manifests containing all our app URLs, one
   protected by a cookie and one not. This proposal wouldn't completely ease
   this problem, but if we're executing a script before the page is loaded we
   have more options for redirecting to another page when not authenticated,
   more similar to the way most online authentication schemes work.

Also, there are some cases where Javascript simply is not powerful enough.
An example we hit recently is dynamic data in the header (e.g., meta tags,
styles). We have many cases where these change dynamically. There are ways
to get around this (put the dynamic page in an iframe, construct HTML in
javascript, and writer it into the iframe), but I think it's clear that this
is not a great solution. This is processing that should happen before the
page is handed to the browser.

- Philip

> *Scriptlets - or dynamic namespace-handlers [new idea]*
>
> Something we wrestled with in the process of putting together the Gears
> LocalServer was the distinction between intercepting requests for urls and
> identifying the appropiate cached resource for that request. We ended up
> with a declarative manifest file, similar to but different from what is
> contained in this spec. This wasn't an altogether satisfying answer. The
> expressiveness of the language to match/filter requested urls is limited
in
> Gears and this spec shares that same characterization.
>
> Something else we've wrestled with in Gears was having to do awkward
> redesigns in corners of a web application in order to 'take it offline',
> single-sign-on for example. In general, anywhere an application relies on
> HTTP features more than HTML to influence navigation or conditional
resource
> loading, it's difficult to address with a static cache.
>
> So I'd like to propose extending this spec to incorporate 'dynamically
> generated responses'. I think this capability fits into this corner of the
> HTML5 spec because this is most directly useful in the "Offline Web
> Application" scenario. The basic idea is to execute application code
> (script) to produce responses to intercepted resource loads. The
application
> code is executed in the background and can formulate a response
> asynchronously.
>
> Some handwaving where this could hang off of this spec
> * Modify namespace-handlers entries to have an attitional attribute to
> indicate that they are to be executed rather than returned
>
> And some handwaving at what a scriptlet can do...
> * Can read the request headers and POST body
> * Can set response status code and headers (redirects)
> * Can generate a textual response body
>  * Can designate a non-executable cached resource to be returned in
response
> * Can decide to 'bypass' handling of a request and defer to the usual
> resource loading
> * Can decide to perform the usual resource loading, but to have the
response
> added to the appCache
> * Can access HTML5Database APIs
> * Can utlize XmlHttpRequest to communicate with a server
>
> This would obviously be significant addition to the spec, but i do think
> this is worth consideration in the context of 'offline applications'.
Based
> on observations of app developers wrestling with Gears, there have been
> several pain points. The HTML5ApplicationCache addresses one of them
> with per-application caches. This addition would address the second of
> them.  (Another pain point has been application deployment).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081003/d4446d96/attachment.htm>