It takes a bit of time to accept that Gears is not a bottled offlinifier for sites. It takes even more time to accept that it’s not even an end-user tool, or something that just shims between the browser and the server and somehow saves you from needing to rethink how you approach the Web to take it offline. That the primitives, offered by Gears, are an enabling technology that gives you the capability to make completely new things happen on the Web, and it is your, developer’s task to apply it to solve problems, specific to your Web application.

And it’s probably the hardest to accept that there is no one-size-fits-all solution to the problem of taking your application offline. Not just because the solution may vary depending on what your Web application does, but also because the actual definition of the problem may change from site to site. And pretty much any way you slice it, the offline problem is um, hard.

It’s not surprising then that all this thinking often leaves behind a pretty cool capability of Gears: the workers. Honestly, workers and worker pools are like the middle child of Gears. Everybody kind of knows about them, but they’re prone to be left behind in an airport during a family vacation. Seems a bit unfair, doesn’t it?

I missed the chance to see Steven Saviano‘s presentation on Google Docs, but during a hallway conversation, it appears that we share similar thoughts about Gears workers: it’s all about how you view them. The workers are not only for crunching heavy math in a separate thread, though that certainly is a good idea. The workers are also about boundaries and crossing them. With the cross-origin workers and the ability to make HTTP requests, it takes only a few mental steps to arrive at a much more useful pattern: the proxy worker.

Consider a simple scenario: your JavaScript application wants to consume content from another server (the vendor). The options are fairly limited at the moment — you either need a server-side proxy or use JSON(P). Neither solution is particularly neat, because the former puts undue burden on your server and the latter requires complete trust of another party.

Both approaches are frequently used today and mitigated by combinations of raw power or vendor’s karma. The upcoming cross-site XMLHttpRequest and its evil twin XDR will address this problem at the root, but neither is yet available in a released product. Even then, you are still responsible for parsing the content. Somewhere along the way, you are very likely to write some semblance of a bridge that translates HTTP requests and responses into methods and callbacks, digestible by your Web application.

This is where you, armed with the knowledge of the Gears API, should go: A-ha! Wouldn’t it be great if the vendor had a representative, who spoke JavaScript? We might just have a special sandbox for this fella, where it could respond to our requests, query the vendor, and pass messages back in. Yes, I am talking about a cross-origin worker that acts as a proxy between your Web application and the vendor.

As Steven points out at his talk (look for the sessions on YouTube soon — I saw cameras), another way to think of this relationship is the RPC model: the application and the vendor worker exchange messages that include procedure name, body, and perhaps even version and authentication information, if necessary.

Let’s imagine how it’ll work. The application sets up a message listener, loads the vendor worker, and sends out the welcome message (pretty much along the lines of the WorkerPool API Example):

// application.js:
var workerPool = google.gears.factory.create('beta.workerpool');
var vendorWorkerId;
// true when vendor and client both acknowledged each other
var engaged;
// set up application listener
workerPool.onmessage = function(a, b, message) {
  if (!message.sender != vendorWorkerId) {
    // not vendor, pass
    return;
  }
  if (!engaged) {
    if (message.text == 'READY') {
      engaged = true;
    }
    return;
  }
  processResponse(message);
}
vendorWorkerId = workerPool.createWorkerFromUrl(
                                'http://vendorsite.com/workers/vendor-api.js');
workerPool.sendMessage('WELCOME', vendorWorkerId);

As the vendor worker loads, it sets up its own listener, keeping an ear out for the WELCOME message, which is its way to hook up with the main worker:

// vendor-api.js:
var workerPool = google.gears.workerPool;
// allow being used across origin
workerPool.allowCrossOrigin();
var clientWorkerId;
// true when vendor and client acknowledged each other
var engaged;
// set up vendor listener
workerPool.onmessage = function(a, b, message) {
  if (!engaged) {
    if (message.text == 'WELCOME') {
      // handshake! now both parties know each other
      clientWorkerId = message.sender;
      workerPool.sendMessage('READY', clientWorkerId);
    }
    return;
  }
  // listen for requests
  processRequest(message);
}

As an aside, the vendor can also look at message.origin as an additional client validation measure, from simple are you on my subdomain checks to full-blown OAuth-style authorization schemes.

Once both application and the vendor worker acknowledge each other’s presence, the application can send request messages to the vendor worker and listen to responses. The vendor worker in turn listens to requests, communicates with the vendor server and sends the responses back to the server. Instead of being rooted in HTTP, the API now becomes a worker message exchange protocol. In which case the respective processing functions, processRequest and processResponse would be responsible for handling the interaction (caution, freehand pseudocoding here and elsewhere):

// vendor-api.js
function processRequest(message) {
  var o = toJson(message); // play safe here, ok?
  if (!o || !o.command) {
    // malformed message
    return;
  }
  switch(o.command)
    case 'public': // fetch all public entries
      // make a request to server, which fires specified callback on completion
      askServer('/api/feed/public', function(xhr) {
        var responseMessage = createResponseMessage('public', xhr);
        // send response back to the application
        workerPool.sendMessage(responseMessage, clientWorkerId);
      });
      break;
    // TODO: add more commands
  }
}

// application.js
function processResponse(message) {
  var o = toJson(message);
  if (!o || !o.command) {
    // malformed message
    return;
  }
  switch(o.command) {
    case 'public': // public entries received
      renderEntries(o.entries);
      break;
    // TODO: add more commands
  }
}

You could also wrap this into a more formal abstraction, such as the Pipe object that I developed for one of my Gears adventures.

Now the vendor goes, whoa! I have Gears. I don’t have to rely on dumb HTTP requests/responses. I can save a lot of bandwidth and speed things up by storing most current content in a local database, and only query for changes. And the fact that this worker continues to reside on my server allows me to continue improving it and offer new features, as long as the message exchange protocol remains compatible.

And so you and the vendor live happily ever after. But this is not the only happy ending to this story. In fact, you don’t even have to go to another server to employ the proxy model. The advantage of keeping your own server’s communication and synchronization plumbing in a worker is pretty evident once you realize that it doesn’t ever block UI and provides natural decoupling between what you’d consider the Model part of your application. You could have your application go offline and never realize it, because the proxy worker could handle both monitoring of the connection state and seamless switching between local storage and server data.

Well, this post is getting pretty long, and I am no Steve Yegge. Though there are still plenty of problems to solve (like gracefully degrading this proxy model to a non-Gears environment), I hope my rambling gave you some new ideas on how to employ the worker goodness in your applications and gave you enough excitement to at least give Gears a try.

Step 1: Create ASP.NET Application

First, we start with the ASP.NET part of the application, which is largely drag-n-drop:

• Create new database, named YourTimesheets.
• In this database, create a table Entries, with the following fields (you can also run this script):
  • ID int, this will also be our identity field
  • StartDateTime datetime
  • DurationsMin int
  • Project nvarchar(100)
  • Billable bit
  • Comment ntext
• In Visual Studio 2005, create an ASP.NET project, also named YourTimesheets.
• In design mode, drag SqlDataSource from Toolbox bar onto the Default.aspx file.
• Specify the connection string using SqlDataSource designer, pointing to the newly created database (figure 1). Save the connection string in Web.config (figure 2).
• Then, drag GridView onto the same design surface and connect it to the data source (figure 3 and figure 4).
• Now, the input form. I added mine by hand, by you can use the same drag from Toolbox technique to get yours (figure 5).
• Hook up the form fields and SqlDataSource INSERT query (figure 6). You don’t have to do anything but point and click here.
• Finally, go to the Default.aspx.cs code-behind file and make sure that the Postback saves form data by typing (gasp!) a C# statement (listing 1). Notice that I also added a self-redirect there to make sure that the page is always rendered as a result of a GET request. This may seem odd to you, but how many times did you hit Refresh on your browser and saw the woo wee! let’s repost the data you just entered, again! message? This one-liner prevents that situation.
• At this point, you have a fully functional ASP.NET timesheet entry application, but let’s go ahead and add some styling to it (figure 7 and listing 2).

It is probably worth mentioning that no amount of styling will fix some obvious usability problems with the data entry in this particular piece of user interface, but hey, I didn’t call this article ASP.NET on Gears: A Production-ready Application, right?

Step 2: Develop Gears Application Concept

Moving on to Gears stuff. This part of the show contains graphic hand-coding and conceptual thinking that may not be appropriate for those who build their stuff using the Toolbox bar and Design View. People who are allergic to Javascript should ask their doctor before taking this product. Just kidding! You’ll love it, you’ll see … I think. For this tutorial, I chose to use the 0.2.2.0 build of Gears, which is not yet a production build, but from what I heard will be shortly. This build offers a quite a bit more functionality for workers, such as HttpRequest and Timer modules, and as you’ll see shortly, we’ll need them in this application. Let’s first figure out how this thing will work. When connected (online), the application should behave as if Gears weren’t bolted on: entry submissions go directly to the server. Once the connection is severed (application goes offline), we can use LocalServer to serve application resources so that the page still comes up. Obviously, at this point we should intercept form submission to prevent the application from performing a POST request (those are always passed through the LocalServer). As we intercept the submission, we put the submitted data into a Database table. Then, when back online, we replay the submissions back to the server asynchronously, using WorkerPool and HttpRequest, reading from the Database table. Speaking of back online, we’ll need some way to detect the state of the application. We’ll do this by setting up a WorkerPool worker, making periodic HttpRequest calls to a URL that’s not registered with the LocalServer. When request fails, we deem the state to be offline. When request succeeds, we presume that things are online. Simple enough? To keep our dear user aware of what’s going on, we’ll need to do quite a bit of DOM manipulation. No, not that Dom. This DOM. For instance, the data, entered offline should be displayed for the user in a separate, clearly labeled table. We will also need to know of events like the user attempting to submit the form, so that we could intercept the submission and stuff it into Database. Oh, and there’s one more thing. Since we build this application to operate both offline and online, we can’t rely on server-based validation. For this task, I chose to write my own client-side validation, but you can try and tinker with the standard ASP.NET 2.0 validation controls and the crud they inject in your document. To summarize, we need the following components (let’s go ahead and name them, because naming things is fun):

• Database, to write and read entries, entered offline.
• DOM, to intercept submits, changes of input values, writing offline entries table, and other things that involve, well, DOM manipulation.
• Monitor, to poll server and detect when the application becomes offline and online.
• Store, to keep track of the resources that will be handled by LocalServer when application is offline.
• Sync, to relay submitted offline data back to the server.
• Validator, to ensure that the field data is valid before it’s submitted, whether online or offline.

Step 3: Define Interfaces

Piece of cake! The only thing left is writing some code. Perhaps we should start with defining how these pieces of the puzzle will interact. To keep code digestible and easy to hack on (it’s a tutorial, right?), we will make sure that these interactions are clearly defined. To do that, let’s agree on a couple of rules:

• Each component exposes a consistent way to interact with it
• A component may not call another component directly

It’s like an old breadboard from your science club tinkering days: each component is embedded into a block of non-conductive resin, with only inputs and outputs exposed. You plug the components into a breadboard and build the product by wiring those inputs and outputs (figure 8). In our case, since our components are Javascript objects, we’ll define an input as any Javascript object member, and an output as an onsomethinghappened handler, typical for DOM0 interfaces. And here we go, starting with the Database object, in the order of the alphabet:

// encapsulates working with Gears Database module
// model
function Database() {

    // removes all entries from the model
    this.clear = function() {}

    // opens and initializes the model
    // returns : Boolean, true if successful, false otherwise
    this.open = function() {}

    // reads entries and writes them into the supplied writer object
    // the writer object must have three methods:
    // open() -- called before reading begins
    // write(r, i, nextCallback) -- write entry, where:
    // r : Array of entry fields
    // i : Number current entry index (0-based)
    // nextCallback : callback function, which must be called
    // after the entry is written
    // close() -- called after reading has completed
    this.readEntries = function(writer) {}

    // writes new entry
    // params : Array of entry fields (StartDateTime, DurationMins,
    // Project, Billable, Comment, FormData)
    this.writeEntry = function(params) {}
}

It’s worth noting that the readEntries method mimics the archetypical Writer and asynchronous call patterns from the .NET framework. I hope you’ll think of them as the familiar faces in this crowd. The DOM component has the most ins and outs, primarily because, well, we do a lot of things with the browser DOM:

// encapsulates DOM manipulation and events
// view
function DOM() {

    // called when the browser DOM is ready to be worked with
    this.onready = function() {}

    // called when one of the inputs changes. Sends as parameters:
    // type : String, type of the input
    // value : String, value of the input
    this.oninputchange = function(type, value) {}

    // called when the form is submitted.
    // if it returns Boolean : false, the submission is cancelled
    // submission proceeds, otherwise
    this.onsubmit = function() {}

    // hooks up DOM event handlers
    this.init = function() {}

    // loads (or reloads) entries, entered offline by creating
    // and populating a table just above the regular timesheets table
    // has the same signature as the writer parameter of the
    // Database.readEntries(writer)... because that's what it's being
    // used by
    this.offlineTableWriter = {
    open: function() {},
    write: function(r, i, nextCallback) {},
    close: function() {}
    }

    // provides capability to show an error or info message. Takes:
    // type : String, either 'error' or 'info' to indicate the type of
    // the message
    // text : String, text of the message message
    this.indicate = function(type, text) {}

    // grabs relevant input values from the form inputs
    // returns : Array of parameters, coincidentally in exactly the
    // format that Database.writeEntry needs
    this.collectFieldValues = function() {}

    // returns : String, URL that is set in of the form action attribute
    this.getPostbackUrl = function() {}

    // removes a row from the offline table. Takes:
    // id : String, id of the entry
    this.removeRow = function(id) {}

    // remove the entire offline table
    this.removeOfflineTable = function() {}

    // enable or disable submit. Takes:
    // enable : Boolean, true to enable submit button, false to disable
    this.setSubmitEnabled = function(enable) {}

    // iterate through fields and initialize field values, according to type
    // Takes:
    // action : Function, which is given:
    // type : String, the type of the input
    // and expected to return : String, a good initial value
    this.initFields = function(action) {}
}

Monitor has a rather simple interface: start me and I’ll tell you when the connection changes:

// provides connection monitoring
// controller
function Monitor() {

    // triggered when connection changes
    // sends as parameter:
    // online : Boolean, true if connection became available,
    // false if connection is broken
    this.onconnectionchange = function(online) {};

    // starts the monitoring
    this.start = function() {}
}

Is this a simplicity competition? Because then Store takes the prize:

// encapsulates dealing with LocalServer
// model
function Store() {

    // opens store and captures application assets if not captured already
    // returns : Boolean, true if LocalServer and ResourceStore
    // instance are successfully created, false otherwise

    this.open = function() {}
    // forces refresh of the ResourceStore
    this.refresh = function() {}
}

Synchronization algorithm in this tutorial is exceedingly simple, we basically just start it and wait for it to complete. As each entry is uploaded, the Sync component reports it, so that we could adjust our presentation accordingly:

// synchronizes (in a very primitive way) any entries collected offline
// with the database on the server by replaying form submissions
function Sync() {

    // called when a synchronization error has occured. Sends:
    // message : String, the message of the error
    this.onerror = function(message) {}

    // called when the synchronization is complete.
    this.oncomplete = function() {}

    // called when an entry was uploaded to the server. Sends:
    // id : String, the rowid of the entry
    this.onentryuploaded = function(id) {}

    // starts synchronization. Takes:
    // url : String, the url to which to replay POST requests
    this.start = function(url) {}
}

Finally, the Validator. It’s responsible both for providing good initial values for the form, as well as making sure the user is entering something legible.

// encapsulates validation of values by type
function Validator() {

    // provides good initial value, given a type. Takes:
    // type : String, the type of the input, like 'datetime' or
    // 'number'
    // returns : String, initial value
    this.seedGoodValue = function(type) {}

    // validates a value of a specified type. Takes:
    // type : String, the type of the input.
    // value : String, value to validate
    // returns : Boolean, true if value is valid, false otherwise
    this.isValid = function(type, value) {}
}

Whew! Are we there yet? Almost.

Step 4: Write Code

This is where we pull up our sleeves and get to work. There’s probably no reason to offer a play-by-play on the actual process of coding, but here are a couple of things worth mentioning:

• Javascript is a dynamic, loosely-typed language. Enjoy it. Don’t square yourself into compile-time thinking. This is funk, not philharmonic.
• Javascript is single-threaded. The trick that you might have learned with 0-timeout doesn’t actually start a new thread. It just waits for its opportunity to get back on the main thread.
• Gears workers, on the other hand, are truly multi-threaded. There is some pretty neat plumbing under the hood that sorts out this dichotomy by queueing the messages, and you might want to be aware of that when writing the code. For instance, calling main thread with UI operations from a worker doesn’t make them asynchronous: the message handlers will still line up and wait for their turn. So, if your worker does a lot of waiting on the main thread, you may not see as much benefit from using the worker pools.
• Gears currently lack a database or resource store management console with slick user interface (hint: you should perhaps join the project and lend a hand with that). But dbquery and webcachetool are good enough. For this project, I cooked up asmall pagethat, upon loading, blows away all known state of the application, and that was pretty handy in development (listing 3).
• There is a very simple way to simulate offline state on your local machine. It’s called iisreset. From command line, run iisreset /stop to stop your Web server and you’ll have a perfect simulation of a broken connection. Run iisreset /start to get the application back online.

Armed with these Gear-ly pearls of wisdom, you jump fearlessly on the interfaces above and get coding. Or… you can just see how I’ve done it (listing 3

).

Step 5: Feed the Monkey

Feed the monkey? Wha… ?! Just wondering if you’re still paying attention. Technically, we’re done here. The application is working (to see for yourself, download the screencast or watch it all fuzzy on YouTube). As you may have gleaned from our coding adventure, Google Gears offers opportunities that weren’t available to front-end developers before: to build Web applications that work offline or with occasionally-available connection, to add real multi-threading to Javascript, and much more. What’s cool is that Gears are already available on many platforms and browsers (including Internet Explorer), and the list is growing quickly. Perhaps PC World is onto something, calling it the most innovative product of 2007. But don’t listen to me: I am a confessed Gearhead. Try it for yourself.

I am ok! I am ok! And better for it! This time, I am back with the vengeance. Why fight the change? Embrace it! Dear reader, allow me to present the HTML5 SQL Player, a tool that spec developers and curious bystanders alike can use to poke and prod the spec in action. Essentially, this is a Google Gears-based sandbox, in which a user can run Javascript code to query and test the interfaces, implemented by the specification. If I were into that kind of thing, there would be a picture of a crazy-eyed Christopher Lloyd and some reference to the movie that doomed his career. Yes, my friends, this sandbox is a glimpse into the yet-to-be-implemented technology.

And as such, beware of the bleeding edge. Some things in the spec are somewhat under… erm… specified (like the mode of transaction and its effect on sequential calls of the transaction method) and some things in the sandbox are under… erm… implemented (like changeVersion or SQL sanitation). But regardless, this approach is still the best if you’re trying to evaluate spec’s viability in an effort to make it better. And that’s what this is all about.

The truth is, I no longer believe in the necessity (or usefulness) of the audience-based navigation for a University. There, I said it. Having been the advocate for the last 8 years, I eventually came to realize that all it does is create an extra barrier for the user (umm, who am I? Which is the right door?) and is mostly ignored by the visitors, anyway (I am basing this on my observations and thought experiments).

Self-selection is a myth: as you probably know, the user commonly belongs to multiple or none of the offered audiences, and this artificial ritual of forcing the visitor to put the right hat on is not only confusing, it’s actually a little bit insulting.

What’s the alternative? Concentrate on three things:

• Needs-based Clusters. Envelop topics, relevant to specific needs (How do I become a student?) into a cohesive (spit-and-polished!) and limited in scope sites.
• Lifeline Links. Identify 3-5 most desperate and immediate needs of your visitor (I have to check my grades) and by golly, put them on the home page.
• Ambient Findability. Make sure that each page on your site carries a potential of getting the user closer to achieving their goals.

That’s all for now. I am eager to hear your thoughts and opinions on my little turn-about.

After getting my sandbox permit, I hastily cooked up two simple gadgets, er.. social applications, the Twitter and the OpenZombie. Both of these are skeletal proofs-of-concept, on whose I have no intention to continue development. So, feel free to borrow in parts or in whole — it’s public domain, baby! I intentionally tried to keep them light-weight, client-side-only. Both have been casually tested with Firefox and IE7. In other words, don’t call me if you have a problem running either.

First application grabs data from Twitter using Gadget API calls and renders it to somewhat resemble a Twitter feed. It doesn’t actually use any of the OpenSocial API functionality and can be run in the iGoogle. It does use the UserPrefs to ask for the Twitter username, and Orkut’s current way of dealing with this is rather jarring, so be prepared for that.

Second one is my 45-minute take on the ever-ridiculous Zombies application on Facebook. Except this one actually bites automatically. As soon as the user stumbles upon my profile page, they are bitten by the OpenZombie application (with the corresponding activity stream message), and offered to install the application themselves as a vengeance-laden consolation prize. No stats are kept (and that would be hard, given that API doesn’t yet allow you to update owner’s person data), and no blood-curdling imagery is displayed. I figured, the next guy will come along and make it pretty. And by pretty I mean despicably horrific.

Speaking of the next guy, here are a couple of tips that I have for you:

• When debugging the application, appending &bpc=1 to the URL of the page itself will disable caching of the application. Someone already built a Greasemonkey script for that.
• Modularize your development. Make your application a harness that calls scripts and styles remotely:

<Module>
	<ModulePrefs [attributes go here]>
		<Require feature="opensocial-0.5"/>
                [more feature requirements go here]
	</ModulePrefs>
        [user prefs, etc. go here]
	<Content type="html">
	<![CDATA[
		<script type='text/javascript'
			src='[absolute script url]'></script>
		<style>
			@import url('[absolute style url');
		</style>
		<div id="message"></div>
		<div id="panel"></div>
 	]]>
  </Content>
</Module>

Then, in your script, do something like this:

_IG_RegisterOnloadHandler(function() {
        // your code goes here
});

• Once you have modularized your application, you can do another simple trick: edit your hosts file to temporarily point the hostname in the script and style URLs to localhost. Then make sure that these files are accessible from your local web server. Now you can edit them and see the changes without having to push the files to the server on which the application will eventually be hosted. Just don’t forget to remove the edits in the hosts file when you’re done developing.

Now, for a quick technology review of the OpenSocial Javascript API (can’t speak for the GData stuff, haven’t played with it). On the contrary to the few negative reactions in the blogosphere, I find OpenSocial pretty impressive. I think the API is easy to learn and follow, the transparent authentication and identity data management model is neat, and there’s plenty of room to play, or even build something useful. Bringing application development into the Javascript domain is a good thing. Yeah, the sandbox squeaks and rattles, but that’s typical for an early release. Give it a little time.

The API itself is wordy and a bit inelegant, though this may be a viewpoint,
skewed by the laconic beauty of JQuery. I am guessing that its current shape is probably a result of being tailored toward the more arcane Javascript
implementations. I can’t find any other explanation for the gratuitous global
namespace pollution or things like API objects having accessible underscored methods/fields.

But my biggest beef is with the Gadget API. With it’s let’s start now, it’s so simple! approach, it practically encourages hacky, spaghetti-style Web development. Adding even a primitive asset management to the XML declaration would be a win-win: developers are nudged to separate behavior, presentation, and markup, and the server gets to know in advance what’s needed to render a gadget, thus providing opportunities for caching, embedding, or aggregating the assets:

<Assets>
    <Asset Type="js" Src="http://example.com/twitter.js" />
    <Asset Type="css"  Src="http://example.com/twitter.css" />
...

Another thing that stood out is the lack of user experience management. Facebook went a long way (they invented their own language!) to keep the consistency of the user interface by offering common primitives, like profile action or the freshly baked board. Walking from application to application, you can easily see where the primitives end and developer’s own creative aspirations begin (and believe me, in 8 cases out of 10, it ain’t pretty). But at least they tried. The only thing that Gadget API has in this regard is handling of user preferences. That’s it. The containing IFRAME is essentially an open canvas. This is something that has to be addressed, especially considering that some partners in the alliance are pretty good about keeping their UX noses clean.

I hesitate to draw any sort of conclusions in regard to direction or
viability of the project. Obviously, this is a very early developer’s
preview, where it’s perfectly acceptable to come across matchsticks and
duct tape. As it stands right now, OpenSocial is certainly not as
well-oriented and focused as Facebook, and Orkut doesn’t make a good sandbox
container, because… well, let’s just say it won’t win any usability
awards. And certainly not visual design awards. Even with that, I can
see fairly clearly what Google wants to become: they want to be the social networking plumbing. Just like their search became the the Internet
for many users, I can speculate that Google hopes to offer free,
ubiquitous, and highly mashable pieces of infrastructure that power the
majority of person and community-centric software on the Web. Ultimately, I don’t believe
it’s a move in a game of chess, but a tiny step in the strategy that reaches much
farther and wider than everyone’s favorite blue-shaded time waster.

… Yes, I am going slide-less from now on. Jeff Keeton and I have already done a couple of browser tabs-only presentations before, and the simple method works as well or better than the slides.

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.

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:

• Support of offline storage and state detection per HTML5 spec
• Client-side database storage support per HTML5 spec
• Threading/Worker model from Gears
• WebRunner
  -like chromeless launch support
• App install feature as recently proposed on Gears Engineers Group

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.

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
Greenfield 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.

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
on
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
SilverFlash
out of the picture here) had this distinct flavor of a dumb terminal
(Crockford
says
3270
— 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
LocalServer,
you can actually move the context engine to the client-side… Hey buddy, an
example wouldn’t hurt, m’kay? 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
marker.
Twitter
boys, 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?
Schmancy-Schmashups,
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’
0.2
bits, I realized that cross-origin
HttpRequest
and
createWorkerFromUrl()
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") {
			wp.sendMessage(getRows.toJSONString());
		}
		// ... more message processing
	}
	// finally, kick-start the whole thing by loading the API
	// URL is fictional, of course
	var api = wp.createWorkerFromUrl("http://google.com/api.js");

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
Eden
inside of an object node, Gears hook up directly in DOM, without creating a
scripting
language runtime and certainly not a new
declarative
presentation format. They organically extend HTML DOM space and DHTML
developer’s horizon. What’s more, the Gearites
openly
commit to making (and
diligently
follow
through
with
) a good effort of helping bring this extension into the new HTML spec. And I
like this thinking.