[whatwg] Google Gears and HTML5

[Robert O'Callahan]

On 5/31/07, Maciej Stachowiak <mjs at apple.com> wrote:

> On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote:
>
> 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."
>

Yeah, but that doesn't say what happens if one or more of the resources
fails to load.

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

Then if you go offline while the app is running, you're in bad shape. (I
think brief periods of connectivity are a common scenario...)

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

That could work.

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

Neither do I, but it's something to think about.

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

That could be handled other ways, perhaps by restructuring the app to use
URI query parameters. I think requiredCookie is an example of something we
don't need in an initial spec. (BTW the Gears docs don't say what happens
when a load matches in multiple stores, possibly by having multiple
cookies...)

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.

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

You can copy, delete and rename items in the cache. I guess I should have
said "mutable" instead of "writable".

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

Agreed. That would be very useful for regular Web apps as well.

Rob
-- 
"Two men owed money to a certain moneylender. One owed him five hundred
denarii, and the other fifty. Neither of them had the money to pay him back,
so he canceled the debts of both. Now which of them will love him more?"
Simon replied, "I suppose the one who had the bigger debt canceled." "You
have judged correctly," Jesus said. [Luke 7:41-43]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20070531/75c7e380/attachment-0001.htm>