- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 30 May 2007 17:49:12 -0700
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
Received on Wednesday, 30 May 2007 17:49:12 UTC