DAVE'S LIFE ON HOLD

A Scheme for Messaging

The past couple weeks I have been actively using a messaging framework for sharing information between both nested contexts (iframes, object tags) and backend services (via XHR and websockets). By defining the simplest protocol that would work in all contexts:

S-expression

And choosing an encoding that is well supported on the web:

JSON

We get a powerful force for making web apps look like Erlang nodes!

'subject', 'verb', predicate objects ...

This pattern has been common across many different languages and is influenced largely by English sentence structures. The key observations to make here:


If you've been following my Self.js work, you'll realize that this last constraint means that if one can represent code as data as an s-expression, one can ship arbitrary code to any node in the predicate objects provided that the recipient platform enables those transformations.

The obvious way of translating the message to an actual invocation is (in Coffeescript)

Actors subject ?verb?.apply(Actors subject , predicate_objects)

where Actors could even be an alias for window or global, or it's own registered namespace object.

The structure here also applies to the web application framework as well. Consider an endpoint that proxies XHR requests across another ESB. Let's say you're a ghetto-rigged organization using SMTP as your message bus. You could define an endpoint:

get '/smtp/:email' ->
Smtp.send @email, @.req.body

Your email recipients, which could be a list of procmail scripts can then simply:

process.stdin.resume()
process.stdin.on 'data', (msg) ->
subject,verb, predicate... = JSON.parse msg
globalsubject?verb?.apply(globalsubject,predicate)

And you now have a functioning system that will allow you to invoke methods of objects on arbitrary machines across the world without much of anything.