Hi Dave,

 

Well what I'm thinking is the language of communication is just Self.  I've done Forth systems that used Forth as their communication protocol and it worked beautifully.  I see no reason why sending a message shouldn't just be modeled directly as a message send :)

 

Sounds good.

 

I've done a lot of apps with XMPP, AMQP, and custom communication protocols over the years, and the lesson I've learned is that it isn't the transport mechanism that matters.  What really matters is what are you shuffling across the wire?  If you're just sending state, you're setting yourself up for failure..  You really have to be sending behavior back and forth to make the system scale.  ESB get this to a degree.  Adding ZeroMQ & Mongrel2, or Ejabberd & Mochweb, or X & Y, is far less important than designing a programming model where pushing a button no a web form literally sends a message to an object on a remote server.

 

I think I agree, though I see ZeroMQ as a replacement for sockets/etc rather than a full featured system like AMQP. I think in ZeroMQ the actual messages are blobs – ZeroMQ only does routing. Which means that you could run a pure Self messaging system over it and take advantage of the handling of the messy underlying connection details.

 

I've actually been building an object to map Self sent over the wire via sockets to Erlang style processes.  It listens on any number of sockets, files, or process ids, and sends a message to the registered delegates.  Globals can be referenced in the messages by name, and sandboxing is done by just using objects which never refer to lobby but use a sandbox* reference to a minimal Self world.

I’m very interested in this. Are you intending to share it?

I have played around with similar ideas and sandboxing turned out to be harder than I thought. In particular to do a proper job, my conclusion was there needed to be VM support for restricting access to primitives and a restructuring of how numbers and strings (amongst other) objects were structured.

ie at the moment you can do things like:

42 lobby blowUpWorld

‘Hello’ _BlowUpWorld

These are certainly fixable.

What are you using for a serialisation/deserialisation mechanism? It would be nice but not necessary to use the normal way of defining Self objects. Unfortunately the Self parser is in the VM and isn’t securable, ie

(| key = blowUpWorld |)

There is code to build an object tree from Self code in the system but I don’t think it does the next step of generating actual Self methods.

My goal with the JS side of things for this is to just have the Self code necessary to render a UI just directly run in JS using the translation scheme I mentioned.  HTML5 canvas + Self + this proxy object => self in the browser.  I'm also thinking about doing a Webkit plugin and just bind the Self VM as a plugin, using this Self <-> JS bridge code to once again embed Self in the browser.

 

Or the Google nativeclient, though the vm does funky things so mightn’t play well in a sandbox.

 

If you have a HTML5/javascript implementation of the Self morphic ‘canvas’ which talks over the wire to a Self world then it might not be too slow even if the world is in the cloud. You could also take something like QT and its inbuilt javascript interpreter and do the same thing to make ‘native’ apps.

 

Cheers,


Russell