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