DSelf extensions & process model changes

[David Goehrig]

Selfers,

The past few months I have been playing around with the latest VM code, and building some extensions to aid in building networked objects that take advantage of modern OS infrastructure. Back when Self was under active development by Sun, none of the current kernel level APIs designed to address the 10k problem for Mac (BSD), Linux, Solaris even existed. And if you've ever programed highly distributed systems, you'll know that kqueue, epoll, and the like are your friends. 

This past week I got to thinking about how I would do message sends in Self to proxy objects with a URI naming convention similar to dself, but with a view towards making to accessible to non-self APIs as well. It struck me that HTTP alone could be used to send messages using a simple scheme:

SELF uri-encoded-string HTTP/1.1\r\n\r\n

Where the handler for this invocation merely decodes the string and then performs it using a delegate. The delegate's enclosing scope would contain a reference to the sender of the message so that the object could reply directly by sending a message back:

HTTP/1.1 200 OK\r\n\r\n
SELF uri-encoded-method-call HTTP/1.1\r\n\r\n

Since we are going to use keepalive by default, we can decouple the ACK code from the message send, and control our behavior and security on both sides. 

If we want to restrict method sends we can use a auth scheme that includes a magic cookie in the headers and use the same P2P request scheme to make use of the socket. 

SELF uri-encoded-method-invocation HTTP/1.1
X-Self-Magic-Cookie: sha1-hashed-shared-secret

And if the shared secret does not match a config that matches the client IP/MAC address we could:

HTTP 403 ACCESS DENIED

>From the point of view of a AJAX component hitting this API from a browser this would provide a means to run code, but not necessarily process anything of a meaningful response. To do that would require the Self object understand how to invoke code on the JavaScript side. The easiest way to do this is to formalize an object interface that processes the body of the OK response as:

this method args

Where the invocation code is

this[method].apply(this,args)

The entire XHR request could easily be encapsulated in Object.prototype.self = function(){} and be made available complete with self method names including the : such as

on:Print:  aHTMLElement aString

The internalized string is a valid method name, just not accessible via dot notation in JS

This approach matched with some VM improvements make self a great language for building dynamic web apps that can also run in native self apps as well. 

Dave