[whatwg] Google Gears and HTML5

[Maciej Stachowiak]

Hey Everyone,

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.

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> I'm hoping we  
can get the Google Gears team to participate here and to identify  
whether the few differences are essential or incidental (perhaps Ian  
already has comments from them on this front.

One thing I'd like to see is some reconciliation between the SQL API  
and the Storage interface. These are two completely separate storage  
mechanisms with different security policies, different access APIs  
(SQL queries vs. simple key/value pairs), and separate storage. I'm  
wondering if the spec really needs both.

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. In this case, it might  
make sense to move the executeSql method to the Storage interface.

The Worker Pools module also seems fairly straightforward: <http:// 
code.google.com/apis/gears/api_workerpool.html>. I suggest just  
adding this mostly as-is if it proves useful (with the obvious  
difference that the message callbacks would become DOM events).

Finally, there is the Local Server module: <http://code.google.com/ 
apis/gears/api_localserver.html>. I think there are a lot of good  
ideas there - the caching layer being transparent to the app in terms  
of URI namespace, and the file upload being done via HTML file input  
controls are both good design. However, the API seems pretty complex  
for what it does.

And lastly, I wonder what other implementors think about this stuff.  
Do you agree that these kinds of APIs should be in browsers directly,  
or would you prefer this be left to the realm of extensions and plugins?

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.

Regards,
Maciej