<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><BR><DIV><DIV>On May 30, 2007, at 8:32 PM, Robert O'Callahan wrote:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><BR><BLOCKQUOTE type="cite"><BLOCKQUOTE style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><PRE>I know Mozilla has considered other approaches to offline web apps, <BR>but I think the LocalServer type approach seems cleaner than <BR>Mozilla's JAR file plan, since it is much more transparent and allows <BR>
local resource caching to be decoupled from the rest of the web app.<BR></PRE></BLOCKQUOTE>JAR files can be fairly transparent ... you can redirect from <A href="http://foo.com/foo/index.html">http://foo.com/foo/index.html </A> to <A href="http://foo.com/foo.jar!/index.html">http://foo.com/foo.jar!/index.html</A>, 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.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>Yes, I think the multiple URIs are a significant hassle.</DIV><BR><BLOCKQUOTE type="cite"> 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.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I believe the update is made atomic to the web app:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><<A href="http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore">http://code.google.com/apis/gears/api_localserver.html#ManagedResourceStore</A>></DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>"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."</DIV><BR><BLOCKQUOTE type="cite"> <BR>Other issues with the Gears API:<BR>-- 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.) <BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR><BLOCKQUOTE type="cite">-- 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. <BR clear="all"></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR><BLOCKQUOTE type="cite">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.<BR></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV><DIV>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.</DIV><BR></DIV>Regards,<BR><DIV>Maciej</DIV><DIV><BR class="khtml-block-placeholder"></DIV></BODY></HTML>