techno.blog("Dion")

We realize that to build great applications that use Gears, we need to provide the right tools. From building applications, I have seen how the development cycle is affected by implementing offline support for example. If you are debugging your application you need to create helper methods that can clean up your local database and resource store for example.

There are various tools that have come along to help work with the database, most of them being web based, and some being local tools (e.g. SQLite Manager).

The team wants to offer more development tools for components such as:

• 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 page

We also want it to be done via dogfood:

We can implement Gears tools as HTML/JavaScript applications that use the Gears APIs themselves. In order to make the tools available to every application, we should package them with Gears and serve them automatically from a special set of URLs of the form: <origin>/__gears__/<tool_name>. For example:

http://www.rememberthemilk.com/__gears__/databases.htmlhttp://www.rememberthemilk.com/__gears__/show_database.html?mydb... etc ...

Serving the Gears tools from within the origin they are manipulating means that we don’t have to add any special debug override to the Gears security model. The tools can manipulate Gears resources because they are being run inside that origin.

There is a minor chance of the __gears__ keyword conflicting with an existing application. We can make this configurable if people think this is a big deal.

We should reuse the existing Gears APIs to implement these tools. In the cases where there is no Gears API to provide a feature, it would be preferable to add the API. For example, there is currently no API to list the databases for a given origin. But there is an outstanding feature request for such an API. We should implement that API it instead of adding something special just for these tools.

Other Future APIs

• Factory API updates
• Blob API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

If you have any other tools that you would like to see, I am all ears.

Disclaimer: This is early days, and who knows what the final API will look like, or if it will even make it. Do you have ideas for cool Gears that make the Web better? Let us know!.