[whatwg] Google Gears and HTML5

[Robert O'Callahan]

*Maciej Stachowiak wrote:*

> Now that Google Gears <http://gears.google.com/> has been announced,
> I'd like to see the features in it added to the HTML5 spec, since
> these are features that should ultimately be a part of basic web
> technology, not an extension.
>
> Agreed...

> Ian has already added a SQL API which is functionally more or less
> equivalent to the Database module <http://code.google.com/apis/gears/
> api_database.html> to the HTML5 spec, here: <http://www.whatwg.org/
> specs/web-apps/current-work/multipage/section-sql.html>
>
> 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.

> Conversely maybe something can be done to make them integrate better,
> perhaps the Storage items appear as a table via the SQL API, in which
> case most of the Storage calls are just a convenience interface, but
> you can still do queries on the same data.
>
> Sounds reasonable.

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

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

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/0dbe9b6d/attachment-0001.htm>