[whatwg] Google Gears and HTML5

[Ian Hickson]

(This thread covered several topics. I'm focussing on the offline web apps 
aspects only at the moment. I shall return to this thread in the future 
for the other aspects.)

On Wed, 30 May 2007, Maciej Stachowiak wrote:
> 
> Now that Google Gears <http://gears.google.com/> has been announced, I'd like
> to see the features in it added to the HTML5 spec, since these are features
> that should ultimately be a part of basic web technology, not an extension.
>
> [...]
> 
> Finally, there is the Local Server module: <http://code.google.com/ 
> apis/gears/api_localserver.html>. I think there are a lot of good ideas 
> there - the caching layer being transparent to the app in terms of URI 
> namespace, and the file upload being done via HTML file input controls 
> are both good design. However, the API seems pretty complex for what it 
> does.
> 
> And lastly, I wonder what other implementors think about this stuff. Do 
> you agree that these kinds of APIs should be in browsers directly, or 
> would you prefer this be left to the realm of extensions and plugins?
> 
> I know Mozilla has considered other approaches to offline web apps, but 
> I think the LocalServer type approach seems cleaner than Mozilla's JAR 
> file plan, since it is much more transparent and allows local resource 
> caching to be decoupled from the rest of the web app.

I've now added an offline Web applications system to HTML5. Comments 
welcome.


On Thu, 31 May 2007, Robert O'Callahan wrote:
>
> JAR files can be fairly transparent ... you can redirect from 
> http://foo.com/foo/index.html to http://foo.com/foo.jar!/index.html, if 
> appropriate, and use relative URIs in your app so the same versions work 
> in both cases. On the server side, maintaining a manifest isn't much 
> different from maintaining a JAR. True, having different URLs for 
> different browsers --- or for the same browser, in different modes --- 
> could be a hassle.

I've not used JARs in the spec's feature.


> On the plus side, JAR files make versioning and consistency incredibly 
> simple.

The spec supports versioning and atomic updates, but does nothing to 
guarentee consistency in the face of an upgrade on the server happening 
during download (much like today, in fact, with upgrades while a user is 
downloading a live Web app).


> It's not clear what the Gears ManagedStore does if it gets a 404 or some 
> other error during an update.

The spec hopefully makes this clear for the offline feature.


> Other issues with the Gears API:
> -- The ManagedStore approach seems to have a problem in the following 
> situation: Suppose an app is updated on the server overnight and I visit 
> the main page in the morning. It starts loading other resources.  
> ManagedStore is going to check the manifest, find that the app needs to 
> be updated, pull down the new resources, and flip to the new version --- 
> more than likely while the app is in the middle of loading. Sure, this 
> could happen normally if I hit the site in the middle of the night at 
> the switchover, but ManagedStore makes this uncommon case common. (This 
> is Dave Camp's example.)

The spec manages this by maintaining multiple versions of the app's cache, 
and notifying the browsing contexts when they can upgrade to the new 
cache.


> -- I think making ResourceStore writable by clients is unnecessary 
> complexity. It's much simpler to maintain the model that the 
> LocalServer/offline cache is really just a cache of the Web. Then there 
> are no issues with enabling/disablings stores, there is no need to add 
> domain restrictions or requiredCookie (i.e. potential security holes) so 
> that different apps can't tread on each other's resources. (So apps that 
> want to refer to a canonical source for JS library files or whatever can 
> still work.)

The HTML5 model doesn't have a way to add files to the cache that didn't 
come from the Web, but it does have ways to generate files that aren't in 
the cache, and to add files to the cache dynamically later. It also has 
the ability for files to end up in multiple caches at different versions.



> I think we're still willing to alter our API, but we want to stick with 
> the simple conceptual model we currently have: a single read-only 
> offline cache that requires minimal management. Perhaps we could figure 
> out how to get versioning and consistency without using JARs. E.g., we 
> might be able to add an API that reads a Gears-style manifest and does 
> an atomic update of the offline cache from it.

The spec basically goes about in the middle of the Gears complexity and 
the JAR simplicity.


On Wed, 30 May 2007, Maciej Stachowiak wrote:
>
> I don't think requiredCookie feature is there solely for writeability 
> reasons, but rather to make the LocalServer cache work even when in 
> normal use they might get different versions of a resource from the 
> server at different times. For example, suppose you have two different 
> gmail accounts with preferences set to different languages.

Currently the HTML5 proposal has no intrinsic support for this (though you 
could cache each set of configurations as a separate app easily enough 
with some server-side support).


On Thu, 31 May 2007, Robert O'Callahan wrote:
> 
> There is one related feature that Gears is missing that we thought app 
> writers might need. Web pages can load other pages and pass parameters 
> to them via URI query params or POST. When you're offline that won't 
> work. Our solution to this is that query parameters in JAR URIs are 
> ignored, so jar: http://foo.com/foo.jar!/query.html?bar=baz just loads 
> jar: http://foo.com/foo.jar!/query.html, but script in query.html can 
> access the query parameters via document.location, and dynamically 
> generate content that the server would otherwise have provided. I think 
> an WHATWG solution should cover this case somehow.

We have "opportunistic caching namespaces" and fallback pages for this.


On Fri, 1 Jun 2007, Chris Prince wrote:
> 
> That is correct.  Gears starts serving a manifest's resources only when 
> everything has been successfully downloaded.  If it gets a 404 it will 
> try again later.
 
So how does a page, once cached, stop being cached? There doesn't seem to 
be a way to end the caching. In HTML5's model, you have to leave a blank 
manifest file forever (or until all your users have been weened off the 
old cache manifest) for applications to lose their cache association.


> The solution should avoid relying on application code.  Or more 
> specifically, developers must always be able to fix a "stuck" app with a 
> server-side push.

Just going to a URI in the HTML5 model will start a refresh of the cache, 
and going to a URI twice will therefore always unstick a site.


> The solution should also avoid any extra delay at request time.

HTML5's doesn't ever increase load time, as far as I can tell.


> Yes, that's exactly what 'requiredCookie' is for.  Some applications 
> need to serve different content for a given URL.  Today, they often make 
> that decision based on the user's cookie.  In an earlier design we had a 
> custom object for tracking sessions, but this was a burden on 
> developers.

Currently there's no built-in support for this.


On Tue, 12 Jun 2007, Robert O'Callahan wrote:
> 
> I think restricting URIs to map to just one resource simplifies things a
> lot.

Yes, but it prevents any kind of resource sharing, and sets up a race 
condition (which cache first, or last, looked at a file, decides what 
version of that file to use).


> Another simplification that our model has is that offline resources are 
> never directly mutated by the client; they are always just a snapshot of 
> server state. These two properties are very appealing... We can also 
> safely support cross-domain offline loads (e.g. to get canonical library 
> scripts, or looking forward to WHATWG-style messaging APIs, cross-domain 
> communication) which I think is hard to do without the latter property.

Agreed. I think HTML5 shares this, despite the different model.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'