[whatwg] Google Gears and HTML5

On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote:


> 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.
> 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.

Yes, I think the multiple URIs are a significant hassle.

> On the plus side, JAR files make versioning and and consistency  
> incredibly simple. It's not clear what the Gears ManagedStore does  
> if it gets a 404 or some other error during an update.

I believe the update is made atomic to the web app:

<http://code.google.com/apis/gears/ 
api_localserver.html#ManagedResourceStore>

"While an update is in progress, resources from the previous version  
(if any) will continue to be served locally. After all resources have  
been downloaded, the currentVersion property will be updated to  
indicate that the new set of a resources are now being served locally  
and the previous version has been removed."

>
> 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.) 

We've brought up the same problem. I thought more about this though -  
the update can only happen while you're online, in which case you  
could do all loads directly from the net (or at least revalidating  
per normal cache policy) while at the same time checking for an  
update. Or else the manifest could be checked before serving from the  
local store and if the version changed in that case let the page load  
live and cache those copies. The transparency of the cache from the  
URI point of view actually helps with solving this, I think. I don't  
think this problem is fundamental.

> -- 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.) For file uploads, I  
> think we should just have a DOM API on form control elements that  
> reads the file data into a binary blob of some sort which can then  
> be stored in Storage or SQL. 

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.

I am not sure what you mean by the resource store being writeable. It  
lets you tweak the set of items stored, but you can't construct an  
item with headers and data and all by hand. It does overload file  
insertion into the local store, which is perhaps needlessly complex,  
but you do want a way to access a file picked by an HTMLInputElement  
without having to round-trip it to the server. Perhaps that feature  
would be better served by API on HTMLInputElement instead.

> 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.

Do you have docs or a spec for your proposed API? We're considering  
working on offline web app support soon in WebKit and we'd like to  
get in sync with other efforts before we start implementing.

Regards,
Maciej

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070530/03a47e69/attachment.htm>

Received on Wednesday, 30 May 2007 22:47:07 UTC