Japanese Gears Gears Future APIs: Logging API
Dec 27

Gears Future APIs: Messaging API

Ajax, Gears, Google, Tech with tags: , , Add comments

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

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

2 Responses to “Gears Future APIs: Messaging API”

  1. miranda Says:

    very good
    buy xanax

  2. wholesale replica handbags Says:

    learning

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'cricket'