techno.blog("Dion")

The browser is a fantastic platform to develop applications on. The reach of the Web is unprecedented and the psychology of “installing an app” versus “going to a web page” is huge.

There are still desktop integration features such as desktop shortcuts that link the browser to the underlying host in a nicer way.

One of the missing links is between the browser and the system tray and notification system.

I want to see a Notification API Gear that allows you to tie this together.

Use Cases

Instead of having to install notification agents for applications that you use such as Gmail and Google Calendar, the notification can be built into the applications themselves. You upload a video to YouTube, and it will get back to you when it is done. You choose to “watch” a particular post on the Web? It tells you when there are updates. Google alerts on certain tags do the same.

I find that in my river there are a few occasions where I want to be interrupted (which notifications can do). Depending on your preferences these occasions may be “when my wife emails” or “when someone talks about some cool Ajax thing” or “when someone emails me directly” or “when someone @twitters me”. If I really want to know, I want a notification. If it is slightly less important, I want an email.

In fact, if it is TRULY important, I may even want a text message. This is where configurability comes in. Growl is an event notification for Mac OS X, and it nails all of this. It abstracts the applications from the user. I can go in and change the dials so I get notifications when I want them, how I want them (e.g. in my face, SMS, email), and what they look like (styling). This also includes being able to turn them off.

I want Growl for the Web. Applications can get permission to add events to a notification queue, and I the user can choose how to deal with those notifications.

The API

The API itself should be as simple as possible. This is pretty much a messaging pub/sub system, where the application can publish messages on a queue for its app, with different message types for the type of events.

var notifier = google.gears.factory.create('beta.notifier', '1.0');
 
notifier.notify({
       application: "My App",
       title: 'warning',
       description: 'some text',
       priority: 2,
       sticky: 'True',
       password: 'Really Secure',
});

Growl allows you to have actions in the message itself. That would mean allowing anchor links in the description in the Web world.

There is also the thought that you could also subscribe to various events from other applications, but that can get messy.

System Tray

This notification system could tie into the system tray, or that could be its own API. I worry about the proliferation of tray icons though :)

Beware

The big worry is that people will start spamming the notification system. This is a real concern, and needs to be seriously considered from the beginning. The balance will be in how much we ask users to do, without asking too much so no notifications ever get turned on. With a growl like system it will be easy to turn on and off notifications per application.

What do you think? Is this a useful API?

Other Future APIs

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

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

I was very fortunate to be the person to accept the award bestowed on the Google Gears team by PCWorld for Most Innovative Product of the Year. It was an honour to get to go to the event to pick it up on behalf of Aaron Boodman, Chris Prince, Othman Laraki, Scott Hess, Mike Tsao, and the entire Gears team.

Also, we would have never gotten this award if it wasn’t for companies like Zoho, Remember The Milk, Salesforce, Oracle, Timepedia, and the others who actually used the platform to extend their applications. Whoever got to decide on who won the awards surely did so by using an application that happened to be powered by Gears, rather than looking through the documentation, or blog posts.

I have to say, I have the tiniest glimpse of what it is like for the actor that wins an award and Kevin Spacey, Robert Dinero, and Client Eastwood were also in the running. Frankly, having the iPhone come in at #2 is a bit of a shocker. I mean, the iPhone is really out there and is pushing a mobile revolution. There were other fantastic products in the top 25, and it was nice to be able to see them all at the event.

The products were very broad. I would walk around and see the odd web site such as Tastebook and Mint, a couple of browsers such as Opera, Maxthon, and some Windows only time and space thingy.

But then there were the guitars, GPS companies, hard drives, batteries, toys, cords, and random car stuff. It was an eclectic bunch to say the least.

The room was full of press, and it again showed me how amazing it was that we got the top spot here. No one knew what Gears really is. “So I download it and it can run applications?” I got to talk to ABC, NBC, CBS, PBS, and other publications and had a fun time talking to people that wanted to see a cute gadget.

But then I got to meet the Editor in Chief of PCWorld, and he got it. He understood that Gears is about the potential to change the way the Web works, to upgrade the Web in place if you will. Gears didn’t win for what came of it in 2007, but what will hopefully happen in 2008. New browsers, improved platforms, a better place to deliver great applications to a growing number of people still jumping onto the net.

There are a couple of pet ideas that I have had with respect to JavaScript and Gears. When you think of Gears as a base platform that can upgrade the Web, you think about the ECMAScript 4 fun in a new way.

A common thought pattern starts with optimism:

*ding* Wow, wouldn’t it be cool if my browser could do X?

or

As a developer, I would love to be able to do Y.

And then you often get to disillusionment:

Bugger, but if IE doesn’t support it, I am screwed.

I think that there is probably a good connection between Hope and Web innovation. I have felt this many times. If I feel like I can do something, I go after it with vigour. On the other hand, if I know that after a ton of work it won’t work for a large number of people, then I am far less likely to take her home.

How does this relate to JavaScript again?

What if JavaScript 2 (ECMAScript 4) comes out at a subset of Web developers are really excited about the new features. They want to get into packaging/namespacing/programming units. They grok optional types and like them. The pythonista in them enjoys the generator-like support. And, I could keep going with the large number of features. After you get over your initial excitement, you think about how a new set of libraries could make life a lot better. Prototype 2 is born that supports JS 2.

And then you start thinking about deployment. Darn it, maybe Microsoft doesn’t support it. Hmm. Of course, this is where the monkey comes in from Mozilla, but I immediately thought that Gears could help here. We could see if a script is asking for JavaScript two, and on demand install Action Monkey or anything else. Maybe together, Gears and the monkey could push out JavaScript 2 in a way that would push Microsoft to implement it themselves at some point (IF they don’t right away!).

What about the script of JavaScript?

I have talked about this a bit before, but I would also love to do smart work with respect to registering libraries enabling sites to not have to re-download and compile them all the darn time. We register Dojo, Prototype, jQuery, YUI, GWT, and [insert your favourite library] in a versioned way, and these versions can even be optimized for a particular browser. Instead of the if (thisbrowser) crud that we still see now and then (instead of the if (FEATURE)) we could have browser specific code, and all of the code can be compiled to be super fast.

When an application loads Dojo v1.0.2, it is swapped in with crazy speed.

If we ever get to this reality, then think about how things change. All of the optimizations and “keep my library to 3kb” arguments change. We always want nice small libraries, but we won’t have to make the compromises that we have had to in the past. We can do more in these libraries.

Gears isn’t the only solution here of course. Browsers can do this too. Ideally, browsers would do it, and Gears would be there to once again mop up for browsers that don’t implement it.

Wot no server?

There is also the server side of the equation. I have long thoughts that:

JavaScript needs a CPAN

It needs to be:

• Crazy fast
• CDN (see: crazy fast)
• Access is given to the projects themselves to manage (not run by one company person)
• Community driven

We have had JSAN, and other sites out there, but we need a big guy to come along. Yahoo! does it for YUI. AOL does it for Dojo. I want someone to do it for everyone. Of course, I would love Google to be that place, but I don’t care who actually does it. Google already has a bunch of people using Google Code to hotlink to their libraries, as it actually fulfills most of the requirements. There are some issues such as the fact that it only works for open source projects, and how it isn’t explicitly made for this purpose.

With script registration, and a fast distributed server for the script, we have a much better place. Add to this new JIT JavaScript VM’s, and 2008+ looks like a different place.

And there is more…

You can also take the case where Gears swaps in a JS 2 engine and generalize it. What if someone came up with a new CSS engine? Or any other library that makes sense to be cross-browser-platform. Hmm.

Other Future APIs

• Crypto API
• Developer Tools
• Factory API updates
• Blog API
• Logging API
• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

As soon as you build richer and heavier applications that have any data or logic on the client, you get into the world of security. Ajax security is a hot topic. On the one hand, the game hasn’t changed at all:

Don’t trust the client!

But we see XSS, CSRF, and other tactics being used to do bad things. With the Gears Database component, we have to think about how safe that data is. Although data on a local machine is a bad thing, we have seen people using encrypted partitions to give some level of security. What if we could have a layer of Crypto in Gears itself? This would mean that a Web developer could use Crypto anywhere in their Web application.

Dojo Offline put encryption on top of Gears. In Dojo SQL you can use a magic ENCRYPT() function in your SQL string and it will be grabbed out and encrypted for you.

“Under the covers Dojo SQL’s cryptography is powered by 256-bit AES,
using the passphrase you provide to derive the key. Specifically, we use
the JavaScript AES implementation given here if you would like to study
how it works; special thanks to Chris Veness for contributing the AES
encryption code to Dojo.”

There are some JavaScript based AES libraries such as ecmaScrypt but the performance tends to be a touch slow. This problem is going away in the future as we see ActionMonkey come alive, as well as other trace based JIT compilers for JavaScript. This is still in future land though, so what about now.

There are some big questions when you really think about what a Gears Crypto API should be:

• How low level should it be? Just a wrapper on something like openssl?
• Should we just put encryption into the existing APIs?
• What are we truly trying to solve here?

In general, when you aren’t sure, you end up getting low level APIs and you sit and wait for developers to built on top of it. This is one area where I would like to see a higher level API. In my experience, Crypto APIs are always too complex and in your face. Often you don’t want to choose a million options. You want to say “Erm, can you just encrypt this really well?”.

Would you like to see a crypto API that you could just use? If so, what would you actually like to see!

Other Future APIs

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

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

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

The simple Gears Factory is the front door to all Gears modules. It is about to get a small update that gives you a touch more configurability.

If you have wanted to customize the popup that your users get when first giving permissions to use the application, you can use the new APIs:

• boolean getPermission(siteName, imageUrl, extraMessage): Lets a site manually trigger the Gears security dialog, optionally with UI customizations.
  • siteName: Friendly name of the site requesting permission.
  • imageUrl: URL of a .png file to display in the dialog.
  • extraMessage: Site-specific text to display to users in the security dialog.
• hasPermission: Returns true if the site already has permission to use Gears.

So, nothing fancy here, but if you want to customize your Gears messages, you will be given control to do so.

Other Future APIs

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

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

Now, the Blob API isn’t going to be something that you will use often, if ever. It is an internal-ish API that other APIs such as the Image Manipulation API will use.

A blob is an object representing file data. It is retrievable, for example, from a resource store or from a HttpRequest or some other source of file data. It can be saved back to a resource store or to a POST request via HttpRequest.

Blob data cannot be accessed from Javascript. Only metadata can be read. Blobs can only be created and modified by other modules.

The external view is simply:

interface Blob {
  readonly attribute int size;
  readonly attribute string contentType;
}

Whereas any Gears module can blob.SetData(otherdata);.

Other Future APIs

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

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

I was a touch surprised to read that Gears came in as #1 in the 25 most innovative products of the year.

On the other hand, maybe they saw the potential for upgrading the Web. The potential is really what I see when I look at Gears. The hope for a better Web. We need help from the entire Web developer community, and beyond.

It turns out they really just saw “offline” == Gears, but that will change in 2008. Here is to the future.

Congrats to Aaron, Chris, Scott, Mike, Othman, and the entire Gears team.

Logging is famously over engineered in Java, with huge abstractions. In JavaScript, the majority of folk still use alert() or write out to the Error Console. Of course, those that know, use Firebug and such.

It would be nice to be able to debug throughout the browsers, and inside of WorkerPools in the Gears world. Rather than reinvent the wheel, our Logging module should be as close to the Firebug API as possible:

class GearsLogger {
  // All these methods interpolate _args_ into _message_, replacing occurrences of _%s_.
  debug(String message, Object[] args);
  info(String message, Object[] args);
  warn(String message, Object[] args);
  error(String message, Object[] args);
}

As we see more of these get out there, I hope that we come together and define some simple logging that developers can be assured of. Having to always use Firebug Lite, or define window.console if the object isn’t there, is a pain.

Other Future APIs

• Messaging API
• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

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

Once you start delving into the WorkerPool API, you quickly see how a common pattern would be using it as a messaging system. As it stands, it looks like an Open Web version of Erlang processes.

Scott Hess wrote up his thoughts on a more formal Messaging API based on WorkerPool:

Gears WorkerPool has two pieces, the part about running a bit of JS asynchronously, and the part about trading messages with that JS. This API may be composable from more basic bits. The messaging bit could be used in other contexts, such as implementing something like WhatWG’s postMessage().

Aside: What is WhatWG’s postMessage?

postMessage is “a messaging system that allows documents to communicate with each other regardless of their source domain, in a way designed to not enable cross-site scripting attacks.”

Here is an example:

For example, if document A contains an object element that contains document B, and
script in document A calls postMessage() on document B, then a
message event will be fired on that element, marked as originating from
document A. The script in document A might look like:

var o = document.getElementsByTagName('object')[0];
o.contentWindow.postMessage('Hello world');

To register an event handler for incoming events, the script would use
addEventListener() (or similar mechanisms). For
example, the script in document B might look like:

document.addEventListener('message', receiver, false);
function receiver(e) {
  if (e.domain == 'example.com') {
    if (e.data == 'Hello world') {
      e.source.postMessage('Hello');
    } else {
      alert(e.data);
    }
  }
}

This script first checks the domain is the expected domain, and then
looks at the message, which it either displays to the user, or responds
to by sending a message back to the document which sent the message in
the first place.

Back to the Gears Messaging API

Scott gives an example of the messaging API, starting with an end point:

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");

To enable cross domain, you can post.open(name, domain), and on the other side, you have to allow it via something like port.allowCrossOrigin(["www.good.com", "www.angelic.com"]);.

I am excited about a messaging API, as I think that it fits into the way in which we are developing new Web applications. Having an asynchronous queue that allows me to replay work (e.g. offline), and work nicely with Comet based interactions, would be great. We can reuse all that we have learned from other event based systems, and Gregor can rename his book and be happy!

Other Future APIs

• Location API
• Desktop Shortcut API
• Image Manipulation API
• Introduction to the series

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