On 5/31/07, Maciej Stachowiak <[EMAIL PROTECTED]> 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]
