Re: Let's make Lua mobile!

[David Hollander <dhllndr@...>]

>XMPP

Let me proposes a different protocol that might suit your needs:

1st and 2 byte: message length
X bytes: message

message = any serialized lua value.

Pass (senderIP, message) to a handler. The end :)

- David Hollander

On Thu, Oct 27, 2011 at 3:28 PM, Ezra Sims <ezra.sims@gmail.com> wrote:
> On 10/27/2011 11:35 AM, Stefan Reich wrote:
>>
>> Hi Ezra!
>>
>> Thanks for your answer!
>>
>> Would XMPP work for sending a frozen script (just a binary image)
>> between different machines?
>
> Yep. Jingle [1] (which most clients and libs support) allows for file
> transfer, or for small amounts of data you could just compress, hex-encode,
> and send the image as a standard message with an identifying prefix for the
> receiver to parse. I'm sure there are plenty of other methods supported by
> the protocol, those are just the two that happen to come to mind first.
>
>> If yes, do you have code to do this? I
>> really want to just start doing it (sending a few scripts around the
>> 'net).
>
> Not at the moment, but I doubt it would take long to come up with something
> workable. I'd start with Verse [2] (I have ready-made squishes and
> test/example code if you have trouble getting it working from the repo) and
> figure out what works from there.
>
>> My own first idea was to use zmq for communication. But I haven't
>> really started exploring it it yet, just informed myself about it a
>> little. If XMPP provides useful, let's go for XMPP.
>
> It depends completely on implementation. I probably know even less about zmq
> than you, but I do know it'll very likely be faster than XMPP if distributed
> computing is involved. XMPP does have the huge advantage of being a chat
> protocol, which makes client discovery and non-binary communication (state
> and overload notifications, handshakes, etc) trivial to implement.
>
> For a lib I'd leave the connection up to the application, defining pluggable
> methods for I/O. At an application level, if I had to pick only one my first
> choice would be XMPP - it takes a *lot* of fairly complex work out of the
> picture. Set up a server, figure out a way to handle registration on the
> client level, call it good.
>
> If speed becomes an issue under an XMPP implementation with no XEP to handle
> things better, perhaps a hybrid approach using XMPP for basic communication
> while ZMQ handles the 'dirty work' of sending and receiving data would work
> well.
>
> There's all sorts of ways, and I'd be happy to collaborate if you'd like.
> Feel free to contact me directly.
>
> -Ezra
>
> [1] http://xmpp.org/extensions/xep-0234.html
> [2] http://code.matthewwild.co.uk/verse
>
>
>