Google Gears Future APIs
Date : 2008 01 02 Category : Tech & Development
Ajaxian
Over on my personal blog I kicked off a series of articles on some future APIs that are on the table for Gears, and how in my opinion, Gears is mistakenly seen to be about "offline", when that is just the surface.
I started off by discussing the Image Manipulation API, "is a module to give Javascript a way to resize, crop and compose images together on the client side. This will allow, for example, images to be resized into a web-friendly format before being uploaded to a photo album. Another use is for composition of images together as an efficient alternative to server-side composition or CSS layering. Yet another use is for basic photo editing - a user can edit a photo with instantly applied changes before uploading it to the server."
Then I went on to the Desktop Shortcut API where you can:
PLAIN TEXT JAVASCRIPT:var desktop = google.gears.factory.create('beta.desktop'); desktop.createShortcut("Test Application", "An application at http://www.test.com/index.html", "http://www.test.com/index.html", {"16x16": "http://www.test.com/icon16x16.png", "32x32": "http://www.test.com/icon32x32.png", "48x48": "http://www.test.com/icon48x48.png", "128x128": "http://www.test.com/icon128x128.png"});
The Location API provides a means to fetch the location of a device running a Web browser with Gears:
The Location API is an abstraction for the various LBS APIs that currently exist on mobile platforms (GPS-based, network/cellid-based). The API consists of the Location class, which encapsulates various location attributes (latitude, longitude, etc), and also provides the means to query the platform for a location fix. This API also adds a new event type that is fired every time the location changes. Location implementations can be straightforward mappings to native LBS APIs (e.g the S60 Location Acquisition API) or have a more complex design that combines several location providers (e.g a GPS-based provider and a cell id-based provider) and returns the location from the most accurate provider at any given time.
The Messaging API fits in with the current WorkerPool API to give you cross domain rich messaging:
PLAIN TEXT JAVASCRIPT:var port = google.gears.factory.create('beta.messageport', '1.0'); port.onmessage = function(port, msg, sender) { alert("message: " + msg); }; port.listen("name"); // Omit for anonymous listener. // and having a way to send it a message: var port = google.gears.factory.create('beta.messageport', '1.0'); port.open("name"); port.sendMessage("hello there");
There there were smaller fry such as a Logging API, the Blob API, and Factory API updates.
To finish off we have the issue of developer tools. We need to make sure developers have the tools they need to enable successful app development using the APIs, so we want to first add:
Database List databases per origin Create new Delete Interactive DB command line (can just use existing /sdk/tools/dbquery.html) LocalServer List ResourceStores (and ManagedResourceStores) per origin ResourceStore and ManagedResourceStore status (last error, update history, etc) command line (like db command line, but pointed at localserver DBs) WorkerPool Show running workers Interactive JS prompt to run JS inside a worker Interactive prompt to send messages to a worker Logging (requires LoggingModule) Show logging in real time as it happens Show historical logging Sort/filter by origin/page of source pageI would love to see what you would like to see, and these thoughts will be the subject of future posts.