HTML5 Wrapper for Gears

This is possibly the lowest-hanging fruit ever. After WebKit folks released their implementation of the HTML5 SQL storage specification, Gears immediately became the odd man out, the non-standards-compliant implementation. Never you mind that this part of the spec is still basically a twinkle in Hixie‘s eye. By adding the SQL bit into the latest WebKit nightlies (Windows users are still blissfully unaware of this, by the way), the legendary Apple team put a symbolic stake into the metaphoric ground: this better not be moving anywhere.

So I thought, why not connect the dots? Gears is a capable and much more mature implementation, both WebKit and Gears use the same SQLite server, so it should be just a matter of writing a simple wrapper to bring Gears back into the standards fold.

So here they are, WebKit’s Stickies running in Firefox with Gears, using a tiny bridge script I wrote (see the screenshot on Flickr if you aren’t inclined to install Gears). If you’re running Firefox 3, you may actually be able to write on those stickies. For Firefox 2 users, the lack of contenteditable support means that you can just create, move, and delete the notes. IE users are SOL‘d, because the Stickies sample uses DOM Level 2 events and other happy standards goodies. Do not let this stop you from using the bridge itself, though: it works in IE just peachy-fine.

The script, as I mentioned before, is laughably small and oh yes, incomplete. But I figured, the openDatabase and executeSql support take you about 80% of the way for most Web application development needs, and should the need for the other 20% arise, I would gladly oblige and be your code monkey.

Gearites and Safaritans, if you feel like I encroached on any of your wonderful work by creating this frankenstein, please let me know and we’ll sort this out.

My iPhone SDK

So, my good friend Steve spills the beans about the upcoming SDK. The crowd screams like girls at the Beatles concert. Even ever-curmudgeonly Dave eeks a “hooray”. And that’s a big deal, my reading acquaintance. Now, I don’t own an iPhone, but I play with one at the local store every other week. And I also am a gearhead, as we’ve discussed before. And, I watch google-gears and
WHATWG groups like a hawk whenever there’s talk about gear-related stuff.

With all that, it is only logical to assume that I am siding with Chris on the mournful thoughts for the Web-based application development on the delectable slice of glass-sided aluminum. Because in my opinion, Safari 3 is only five tiny steps away from being a full-fledged application platform.

These steps are:

The “nice-to-haves” and “coming-soons” may include direct TCP Network connections, history and browsing context management, and other neat things from the HTML5 spec, but those first five is what could really make the Web applications first-class. Think about it.

HighEdWebDev 2007

The HighEdWebDev 2007 conference begins tomorrow and I am all ready to go. This is my second year to attend this gathering. Last year, I was sitting at the vendor table (Hello, I would you like to buy a pound of CMS?), guest-blogging at, and that’s about it. This year, I (thankfully!) will not be vending software
goods, but I did sign up for guest-blogging. In addition, Jeff
and I will have a post-conference Workshop 2.0, a boundary-busting, mashpit-flavored jam session of collaborative learning.

We’ll start with breaking down the what’s, the who’s, and the why’s of the gnarly beast we all lovingly call Web 2.0. We’ll talk about the traits and the hype, the comers and the goners, but please pelt us with rotten iPhones if we spend more than 20 minutes doing that.

Next, we’ll conduct an exclusive virtual (hold your fingers crossed for Skype) expert panel, discussing what the future holds in store for the Web of tomorrow. The panel will feature several gurus and senseis of the Web, including our own, battle-tested Mark
and Web 2.0’s uncle Chris FactoryJoe Messina. We tried to get Father Tim, but Twitter was down at the time.

In another 20 minutes, we’ll pull the plug on the Skypecast, claiming technical difficulties, and get to the most exciting part of the shop:
the hands-on. In the remaining 2 hours, we will venture to build a new site. Together. Not to compete with the CSS experts next door, we’ll skip the part of finding fun rendering bugs in IE, but rest assured, we’ll follow the process from start to finish. Please bring
your smocks — this is going to get messy.

Armed with our shockingly brilliant collective intelligence, our Team 2.0 will pick the site project, brainstorm goals, audiences, creative concept, doodle wireframes and even say words like AJAX and Controlled Vocabulary. Together, we’ll argue about pros and cons of promotion techniques, mull over minute details of information architecture, decide on underlying technology and discuss details of implementation while the Photoshop geeks in the corner will
be quietly cooking rounded corners, gradients and drop-shadows.

Throughout, we’ll use social networking tools to facilitate the architecture, development, and promotion of the site, making sure to squeeze the most utility out of the Web 2.0 hype. We probably won’t walk away with a real site. But we sure will try. And in the process, we’ll capture and cherish the spirit of
working together and having a good time.

Call Me Gearhead

So, I am playing with Google Gears and I’ve got to tell ya, Gears are brilliant.
And the
Why? Because Gears fulfill the ultimate fantasy of any Web developer in a very
radical way: they cut into the browser (IE and Firefox, currently), deep and
wide, introducing themselves inconspicuously as a DOM facility
(google.gears.factory – hah, clever fellers, aren’t they?). And they bring…
well, I think they bring a bit more clarity into this whole murky future Web
thing. Oh noes, did Dimitri finally cross the line from a grouchy nerd to the
full-blown pundit and started predicting the future? Well, let’s hope not. To
the very least, color me intrigued.

If you’re not familiar with Gears, this blog is probably not the place to learn
it, but basically, it breaks down to three things: local storage
management, isolation/threading model, and cross-origin data and resource
access. Yeah, see? It’s not even the same breakdown as
their site
. But that’s why it’s here on my blog: I can skim over the details
and get to the good stuff. And good stuff it is. I am surprised that the
reaction to Gears is so muted, because they attack the status quo of Web
application (heck, any Web site) development with a deft balestra that
rivals pretty much anything I’ve seen on the market since, well, since
XMLHttpRequest (only took 5 years to «discover» that one, eh?). Here are just a
couple of exciting possibilities that come to mind after playing with the
0.2 code.

Client-side Composition

Up until now, whether we are eager to admit it or not, DHTML applications (and I
am intentionally classifying
out of the picture here) had this distinct flavor of a dumb terminal
— it’s catchy. Besides, I still have a 3812 in my basement. Makes
excellent ballast). The server had to pretty much “print” down the wire the
entire snapshot of a page in a tasty soup of HTML. And that’s on every request.

Google pushed the envelope on client-side composition with GMail and some people
took notice, but by and large, server-side composition reigns supreme. Come to a
page on the Web, and for each ounce of content there is a bucket of context:
navigation, branding elements, context-sensitive link lists, spotlights,
testimonials, you name it — all repeating from page to page, racking up
bandwidth, using up server cycles needed for complex frameworks to sift, sort,
transform and align resources into the darned HTML snapshot. And that’s on
every request
, my teary-eyed readers. I would join you in your sorrow for
all this wasted energy, but I must finish this song… er, post.

See, with server-side composition, it is up to the server to determine the
context of the requested page and generate markup that puts those links and
other context elements together with the content of the page. Let’s isolate this
effort into a separate functional component, and call it the context
engine. To summarize, content engine retrieves content of the page, context
engine evaluates content and mashes it with whatever seems relevant, and hands
it off to be served to the user agent. Funny fact: most modern content
management systems are in fact context management systems. Content engine
is dumb and simple (fetch a page, duh). Context engine is complex, nontrivial,
and a gargantuan resource hog.

With Gears, you can finally have proper client-side storage (not the
cookie-based monster), and thus you can have proper client-side state. And thus
you can implement proper client-side composition. Which means that aside from
the obvious “offlining” of frequently-used, but rarely-changed assets
(static pages, scripts, images, stylesheets) using
you can actually move the context engine to the client-side… Hey buddy, an
example wouldn’t hurt, m’kay?

Let’s suppose that on your site, most pages have a sidebar, displaying the list
of upcoming events, relevant to this page. With server-side context page, each
page arrives as the blob of markup, generated by the context engine. With
client-side context engine, the page only contains:

  • content and optionally, a list of keywords (tags) that describe the
    meaning of content
  • URL to the event feed

Upon loading of the page, the client-side context engine kicks in:

  1. It checks to see if local event repository exists, and if it doesn’t,
    creates one by fetching all events from the provided event feed URL.
  2. It evaluates content/tags against local content repository of events and
    adds relevant event to the sidebar
  3. Makes “get added/updated since” requests to the event feed and updates
    content repository, as well as the sidebar
  4. Removes older events from the repository

When this user goes to the next page, the server doesn’t do anything but serve
content. For the duration of the session (or perhaps some pre-defined interval),
the client-side context engine provides relevant events from its local
repository. The happy, unburdened server sends sloppy kisses to Gears. No
wonder, because now, the only task that requires any meaningful computation is
serving the list of events added or changed since specified date or revision
, this one’s for you.

Decoupling context engine from the server not only makes server’s work easier.
It also makes context engine server-independent. Who says that I should only
pull events from this one server? Why not pull them from that popular news
outlet, online local events site, or Google calendar?
here we come!

Even cooler, the client-side context engine is far better suited to keep the
track of user browsing habits, generating personal taxonomy or tag cloud, and
taking it into the account when evaluating relevancy. Am I the only one who gets
goosebumps thinking about the opportunities?

Worker as Service

While playing with Gears’
bits, I realized that cross-origin
introduce a better, more modular and more secure way of building public
JavaScript APIs. In this new release of Gears (developer-only, for now), the
worker can be loaded from a URL, and this URL does not have to originate on the
same server as the document, in which the worker is created. In essence, you can
load and run a script from another server in a completely isolated context,
and you can exchange messages with this script. And this script
can make HttpRequest calls back to that server. It only takes a small
logical step to see that this script can expose the public API of a Web
application, located on that server, via WorkerPool messaging.

Let’s pretend that I have a Web site that wants to use Google Spreadsheet as
table, listing some goods for sale. Here’s how I would connect to the API using
JavaScript (wildly pseudocoding):

	var wp = google.gears.factory.create("beta.workerpool", "1.1");
	// create message
	var getRows = new Message("getRows");
	// ... perhaps create more messages, with parameters or not
	// set up message handler
	wp.onmessage = function(text, id) {
		var message = Message.fromJSONString(text);
		// API initiates communication
		if (message.command == "ready") {
		// ... more message processing
	// finally, kick-start the whole thing by loading the API
	// URL is fictional, of course
	var api = wp.createWorkerFromUrl("");

Yeah, I am skipping lots of details, but I hope the concept is obvious: the
Spreadsheet API handler is loaded as a worker, and the page can then use this
API by exchanging a documented set of messages. No need to knit
double-frames or server-side proxies. It just works.

Because the worker is isolated, we can set up more secure authentication and
increase authentication granularity by accepting only certain messages,
depending on the identity. Also, worker runs as a separate thread, which means
we can do other things while the data is cooking. If it were up to me, I’d be
staying up all night converting all Google API endpoints to this model and
developing a good message exchange protocol. Though I might be getting too old
to stay up all night without dire consequences.

Worker as Module

A reverse of worker-as-service model is worker as module. In this case,
the application accepts cross-origin worker registration via UI, allowing them
to participate via message exchange. For example, Google Reader could
allow users to add plug-ins by allowing the users to enter the URL of the API.
The URL could be an HTML document with some simple markup, referencing the
JavaScript file, containing the plug-in. Easy-peasy. And beautiful.

Thinking Outside of The <object> Box

Finally, let’s pause for a second to ponder the way Gears is implemented.
Instead of building their own
inside of an object node, Gears hook up directly in DOM, without creating a
runtime and certainly not a new
format. They organically extend HTML DOM space and DHTML
developer’s horizon. What’s more, the Gearites
to making (and
) a good effort of helping bring this extension into the new HTML spec. And I
like this thinking.