[self-interest] DSelf extensions & process model changes

[Russell Allen]

Hi Dave,

My question is whether you want to make the language Self worlds use to speak to themselves the same language as web browsers use to speak to servers. It sounds attractive but will it be limiting? 

One idea I have had is if we added an interface to the ZeroMQ library we could build a messaging system with multiple transports and both call-response and multicasting of messages, and then for web apps just put Mongrel2 or similar on the front of it.  It would be really nice if a single messaging mechanism could handle all IO from a running Self world but that might be too much to ask for. :)

Russell


On 11/04/2011, at 12:45 AM, David Goehrig <dave at nexttolast.com> wrote:

> 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
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20110411/6cd036ed/attachment.html>