[self-interest] DSelf extensions & process model changes

[Russell Allen]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20110412/c8a14c32/attachment.html>