Google Gears: next quantum leap after XMLHttpRequest

Not much of great consequence has happened on the javascript, BOM and DOM in recent years since XMLHttpRequest and DOM 1.0. The large proprietary software people (Adobe, Apple, Microsoft, Sun) have all recently tried deploying new lock-in schemes of their own targeting the web to attract web developers into their proprietary, closed-source shackles under various flavours of EULAs and/or restrictions management, all of which will hopefully fail.

Brad Neuberg recently gave an Inventing the Future keynote speech at Yahoo FrontEnd Summit 2007, relating (among many things) that the secret to shaping the future is to be an inventive leader, in turn accomplished by combining leadership, great inventions and good values. There is much truth in that. I would personally add "working in the open" to the list.

This is exactly what Google is presently doing with Gears, which Aaron Boodman presented today (via) at Google Developer Day Sydney:



Google Gears is the next quantum leap in web development since XMLHttpRequest, addressing three of the largest issues with javascript webside development:

• the lack of large scale (gigabyte range) client side storage,
• offline availability of online resources, and
• client side javascript freezing up the browser user interface due to its single-threaded design.

All this, in order to tackle the offline problem, which Brad Neuberg had incidentally been working with in the open for some time already for the Dojo Storage and Offline modules. Gears solves all rather beautifully with these three related but separate modules:

	LocalServer caches and serves resources (HTML, javascript, images, et c.) locally,
	Database stores data locally in a fully-searchable (SQLite) relational database
	WorkerPool makes web applications more responsive by performing resource-intensive operations concurrently and asynchronously

I really recommend watching the half-an-hour presentation for the full story. Gears is already available for Firefox and Internet Explorer, soon for Safari, and, being fully new BSD licensed, allows anyone to port it to any other browser environment too. This is how you evolve the web. It is hardly coincidental that Aaron Boodman, who gave us Greasemonkey (licensed just as liberally) has been on the Gears team and gave the presentation.

SVG challenge: craft an SVG in WGS84 coordinate space

In light of the rather successful outcome of my first SVG challenge (not called such at the time), I present another:

Challenge: craft an SVG with transform/viewbox/clipping settings to map WGS84 (that's latitude/longitude, as real numbers between -90.0/+90.0 and -180.0/+180.0 respectively) coordinates to the Mercator projection (used by Google Maps et al), making the image (conceptually) a client side WMS layer or map canvas object you can draw on via javascript using latitude/longitude coordinates, on top of (for instance) Google Maps.

The outcome of such a feat would be a boom in what you can (tractably) achieve, using only client side tools, in the geomapping department, or map mashups, in broader terms. Feel free to use the Google Maps API, if it helps in the number crunching department. (I have a feeling the linear algebra could and should be pulled off with just well engineered transform matrices, though.)

Useless content-*-type meta tags

I think it was in David Flanagan's Javascript: the Definitive Guide (recommended) that I picked up on the <meta name="content-script-type" content="text/javascript; charset=UTF-8"> tag, and, similarly, content-style-type, which lets you pick a default content-type for the <script> and <style> tags respectively (or so it would seem, to the naked eye).

I can't seem to find the book to verify the phrasing in JSDG, but at the time I read it, it sounded like a lovely way of doing away with the repetitive typing of type attributes for all tags of those kinds, throughout the entire document. Great!

Well, not so.

The HTML DTDs still require those type attributes (if you want your documents to verify as correct HTML), and the purpose of those meta tags is purely senseless standards masturbation mode and not this convenient Don't-Repeat-Yourself way of specifying a type and character set in one place only (so my ;charset=UTF-8 appendix is particularly misleading). The intent? Well, they mark the content type of the tag attributes (onclick="...", ..., style="...") where the HTML standard already declares sensible defaults. The relevant parts of the HTML standard linked above are very fuzzily phrased in terms of setting the default language for a document, so the misinterpretation is certainly very easy to do.

Thus it's not the ideal marriage with the pragmatic minimalist Douglas Crockford's advice of just dropping those type attributes all together and have browsers and web servers do the right thing for you. If you want your web pages to keep working after you have saved them (and their relatively linked required resources) to disk, you'd better keep those type attributes with charset specifications, or your browser will have to guess.

Which might not have been such a bad thing, had they only guessed UTF-8 for anything that could possibly be UTF-8. Oh, well.