[sugar] olpc-games osc protocol

[Simon Schamijer]

Simon McVittie wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Mon, 11 Jun 2007 at 13:06:16 +0200, Simon Schamijer wrote:
>> memosono is using the osc protocol 
>> (http://opensoundcontrol.org/spec-1_0) to communicate with the game 
>> server and to talk to the csound server. I think it is an easy to use 
>> protocol and maybe some other games or activities want to use it as well.
> 
> This protocol seems to be rather like D-Bus, but different. We're using
> D-Bus as the basis for most OLPC things - is there a compelling reason
> not to here?

Probably not. I am used to the osc protocol and successfully used it in 
another project. So it was easy for me to use it in memosono as well. I 
will read through the telepathy specs which probably has features I 
haven't thought of yet.

> In the Telepathy-based collaboration framework Collabora are developing for
> the OLPC (including the Presence Service), activities are shared over
> "tubes". These can currently transport a distributed D-Bus over reliable
> streams, with work in progress to do TCP-like reliable streams between
> peers too. Transporting UDP-like datagrams over tubes, using ICE or
> Jingle for NAT traversal, is a future enhancement.
> 
> The advantage of using Tubes is that we're already thinking about issues
> which prevent peer-to-peer networks from working in practice, mainly NAT
> traversal. Tubes provide a consistent API which will remain consistent
> and transparent as we add additional NAT traversal methods and transport
> mechanisms; the API is also consistent between the server-based and
> link-local collaboration, and any future collaboration mechanisms. We will
> also transport instant messages related to an activity, and the necessary
> metadata to support the Buddy- and Activity-centric programming model used
> in Sugar.

cool. I have seen that this is used in the connect activity. I will read 
through this code then.

> I've only looked at the OSC spec briefly, but you seem to be assuming
> synchronized real-time clocks. Is this a requirement we can impose on XOs?
> If it *is*, we could use it for the link-local communication to provide
> additional ordering guarantees; but I suspect it isn't something we can
> assume.

I am not sure I get you right here - do you mean the deviation of 
distributed audio clocks? osc is only about control messages so this 
should not impose any problems here.

Thanks for the insights,

Regards,
    Simon