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
_______________________________________________
Sugar mailing list
[email protected]
http://lists.laptop.org/listinfo/sugar
