<br><br><div class="gmail_quote">On Mon, Apr 11, 2011 at 7:32 PM, Russell Allen <span dir="ltr"><<a href="mailto:mail@russell-allen.com" target="_blank">mail@russell-allen.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">















<div style="background-color:#fff"><br><div><div><div><div><div><div><div><div><div><div><div>

</div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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.</span></p></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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).</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><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">I’m very interested in
this. Are you intending to share it?</span></p></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I was planning on releasing it on github with a BSD style license.</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><div><div><div><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> </span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"> 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.</span></p></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>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.   </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><div><div>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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.</span></p></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I was planning on using the Transporter, and an extra bit or two.</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><div>

<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">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.</span></p></div></div></div></div></div></div></blockquote><div> </div><div>Bingo! </div></div><div><br></div><div>I was also thinking WebGL + Self might be a very nice to build a virtual world :)</div>
<div><br></div><div>Dave</div><br>-- <br>-=-=-=-=-=-=-=-=-=-=- <a href="http://blog.dloh.org/" target="_blank">http://blog.dloh.org/</a><br>