On Mon, Apr 11, 2011 at 7:32 PM, Russell Allen <mail@russell-allen.com> wrote:

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.


ZeroMQ send length coded strings, like most Erlang sockets do.  ZeroMQ's pub-sub-hub model works well only if you are worried about routing payloads to well known endpoints, and is just another transport layer.  It tends to fall flat when you want an actual broadcast mechanism, and want to receive from unknown endpoints (like with email).

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


I was planning on releasing it on github with a BSD style license.
 

 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.


I'm certain that is true.  The primitives are too dangerous to expose to other people's code. One of the things that I'd like to do is send full objects to remote nodes for processing.   

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.


I was planning on using the Transporter, and an extra bit or two.
 

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.

 
Bingo! 

I was also thinking WebGL + Self might be a very nice to build a virtual world :)

Dave

--
-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/