[Etoys] Sockets vs. tubes

[Bert Freudenberg]

Too bad that "stream tubes" won't be usable soon ... but putting our  
TCP packets into regular tubes might be the simplest in the short term.

- Bert -

Begin forwarded message:

> From: Simon McVittie <simon.mcvittie at collabora.co.uk>
> Date: September 7, 2007 14:36:05  PDT
> To: sugar at lists.laptop.org
> Subject: Re: [sugar] TubeSock?
>
> On Fri, 07 Sep 2007 at 16:15:31 -0400, Benjamin M. Schwartz wrote:
>> I have written a bunch of Python code using Sockets, and I am  
>> trying to port it
>> to Telepathy.  To avoid rewriting, I am considering implementing a  
>> python class
>> that wraps python's Socket interface around a Telepathy  
>> TextChannel.  Is this a
>> bad idea?
>
> Bad idea, as worded - Telepathy text channels carry Unicode text in  
> the form
> of XMPP (Jabber) or link-local-XMPP instant messages, and are
> unsuitable for binary data.
>
> You could write an emulation of (some of) the socket.socket interface
> as a wrapper around a D-Bus tube in a *Tubes* channel, however. Each
> activity gets a Text channel and a Tubes channel (both backed by the
> same chatroom, in fact, but we use XMPP's extensibility mechanisms  
> to cause
> Tubes messages to be ignored by clients that don't understand them).
>
> Depending when you want this code to ship on OLPCs, it might be
> more suitable for you to use stream tubes, which do, in fact, give  
> you a
> real TCP or Unix stream socket to play with (and data passed  
> through it will
> get forwarded through the IM protocol transparently). We haven't  
> nailed down
> the network protocol for stream tubes yet, or tested the current  
> implementation
> much, so we're not supporting them in "OLPC 1.0" (the initially  
> shipped
> version early this autumn), but we'll support them in some future  
> release.
>
> For completeness: in some future future version of the Telepathy
> connection managers we want to have a third type, datagram tubes
> (UDP-like unreliable message transfer), using the same sort of
> mechanisms that we currently use for voice and video streaming -  
> because
> these won't do packet reordering or retransmission for you, they'll  
> be more
> work to use, but will be suitable for developers who care about  
> latency
> (e.g. for real-time action games). I for one want to get OpenArena
> running over these, although probably not on OLPCs :-)
>
> 	Simon
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar