On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)

[Robert McQueen]

C. Scott Ananian wrote:
> I've got a concrete non-technical objection: kids at gamejams
> invariably want to write a multiplayer game.  Almost none succeed.
> This tells me we need a better collaboration API.
> 
> You can argue that this "simple" API should be *on top* of the
> lower-level telepathy (or cerebro) API, and I won't argue.  But we
> need *something* which a 12-year old can use.

Yes. The entire concept of Telepathy Tubes was conceived of by us and
dcbw with these two ideas in mind:

 a) how can we efficiently expose the one-to-many nature of the mesh to
application authors who are already working comfortably with Telepathy
and D-Bus - this resulted in D-Tubes (at the time, this was believed to
be achievable via multicast, and hopefully now with Cerebro, may well be
realistically achievable)

 b) how can we allow existing stream protocols to be used in a way that
allows the Telepathy connection manager to do extra work to establish
connections in the situations where ordinary TCP connections would fail
(you're behind NATs, you're avoiding TCP/IP, whatever) - this resulted
in stream tubes

As I said to Jim when he visited us in (t'other) Cambridge a couple of
weeks ago, any clearer requirements were pretty thin on the ground at
the time, so it wasn't clear to us what the needs of the collaborative
applications would actually be, so we decided to start by making these
available, and see what concrete use cases people came up with.

Unfortunately, we started our implementation work with D-Tubes, and
stream tubes were quite slow to follow, so what actually ended up
happening was the authors of the activities we have adapting to the
quirks of the APIs we initially provided. For instance, Abiword's Write
activity, whose first implementation was a TCP server to which clients
connected, could've been shared via a stream tube with a couple of
method calls, but instead grew a backend which layered these one to one
communications over the one-to-many D-Tube, and I think Record also
contains an implementation of streaming files over D-Tubes.

In reality, and I think the past year or so has shown us, most users of
Telepathy, and Sugar activity authors in particular, shouldn't need to
be be exposed to the vagaries of D-Bus, and certainly not forced to
speak it to make collaborative activities. On the other hand, I'm not
very sure that for beginner programmers, implementing well-behaved
(non-blocking, robust, etc) BSD socket code is that straightforward
either, and doesn't really provide very easy mechanisms for sharing
state between multiple participants.

However, the Telepathy API is inherently extensible and we may also
conceive of further primitives besides D-Tubes and stream tubes which we
can implement to hide some of the the complexities of network
programming (and distributed consistency, etc) from activity authors. Or
as you say, we could provide something which did that on top of
Telepathy, if the current APIs were deemed to be suitable to allow that.
We just need a better idea of what those alternative primitives should
look like.

Regards,
Rob