Hi Russel,<br><br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
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?</blockquote><div><br><div class="gmail_quote">
<div>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 :)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="background-color:#fff"><div><div><div><div></div><div>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. </div>
</div></div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="background-color:#fff"><div><div><div><div> 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. :)</div>
<div><div class="h5"><div><font class="Apple-style-span" color="#FFFFFF" size="1"><span class="Apple-style-span" style="font-size: 1px;"><br></span></font></div></div></div></div></div></div>


</div>



  






</blockquote></div><div><br></div>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.<br>
<br></div><div>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.</div>
<div><br></div><div>Dave<br clear="all"><br>-- <br>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/">http://blog.dloh.org/</a><br>
</div>