[self-interest] DSelf extensions & process model changes

David Goehrig dave at nexttolast.com
Mon Apr 11 19:57:30 UTC 2011

Hi Russel,

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?

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 :)

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.

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.

>  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. :)
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.

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.


-=-=-=-=-=-=-=-=-=-=- http://blog.dloh.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.selflanguage.org/pipermail/self-interest/attachments/20110411/53aebdd7/attachment.html>

More information about the Self-interest mailing list