<div><b>Maciej Stachowiak wrote:</b> <br></div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>Now that Google Gears <<a href="http://gears.google.com/">
http://gears.google.com/</a>> has been announced,  <br>I'd like to see the features in it added to the HTML5 spec, since  <br>these are features that should ultimately be a part of basic web  <br>technology, not an extension.
<br></pre></blockquote>Agreed...<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>Ian has already added a SQL API which is functionally more or less  
<br>equivalent to the Database module <<a href="http://code.google.com/apis/gears/">http://code.google.com/apis/gears/</a> <br>api_database.html> to the HTML5 spec, here: <<a href="http://www.whatwg.org/">http://www.whatwg.org/
</a> <br>specs/web-apps/current-work/multipage/section-sql.html></pre></blockquote>That is sudden :-). Specifying the SQL dialect precisely will be very important here. Someone also has to investigate carefully the issues around exposing SQL to untrusted content. Could be some fun denial of service attacks there.
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"><pre>Conversely maybe something can be done to make them integrate better,  <br>perhaps the Storage items appear as a table via the SQL API, in which  
<br>case most of the Storage calls are just a convenience interface, but  <br>you can still do queries on the same data.</pre></blockquote>Sounds reasonable.<br><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. 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><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>-- 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"><br>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><br>Rob<br>-- <br>"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]