Tomeu and Marco, For the history, both me and another student from MIT tried to implement a connection manager back in January but gave up after a couple of weeks, even with significant help from Daf. We don't claim to be expert python programmers, but spending two weeks on something and still not even having understood what needs to be implemented (let alone implementing it) to get a connection manager going, or exactly how telepathy works was quite frustrating. What is more frustrating is that the telepathy API is no secret, but it seems that there is some distance between the API and how the presence service and telepathy really work on the laptop.
Like Michael pointed out, "there are few people at OLPC who understand and enjoy telepathy". I think this is an understatement. Personally, I think that Collabora was very pressed to get something working on the laptop and the resulting presence stack looks like one hack on top of another. For example, there are tons of abstraction layers, yet activities have visibility (while they shouldn't) on how telepathy works (since telepathy is only a dependency to sugar, this should not be the case). Also, the presence service needs to understand if it should switch from salut to gabble, but the broadcast storm caused by salut won't let XO get an IP address through DHCP, which would mean that there's a school server around and..... you get the picture! The current plan to attack scalability problems is implementing gadget from scratch which, if I understand correctly, is a plug-in to jabber which already has many problems of its own. Are we sure we're investing our limited time in the right direction? Personally, I don't think this is entirely Collabora's fault. I also think that if you want to have "distinct yoke and white", this is where you should start: Make telepathy dead-simple to understand by reading the code, not the API. I did a funny activity showing XOs and their relative distance (http://www.olpcnews.com/hardware/wireless/xo_space_where_you_are.html) almost a year ago in a couple of afternoons, when there was no hint of Sugar APIs (not even hippocanvas!) because it was dead-simple to inspect other activities' code and how sugar works. Which brings us to cerebro. Since I got stuck with telepathy, I decided to circumvent telepathy altogether, at the very least as a proof of concept for cerebro's functionality. The result is an API (http://wiki.laptop.org/go/Cerebro#Programming_API ) that offers not only presence and data sharing between activities, but is also a /complete collaboration framework/: you can share/join activities, get a list of all currently shared activities and users participating in them, invitations, out-of-band chat, interoperability with Windows, embedded Linux and OpenMoko (collaboration tested on all these platforms) and most importantly, scalability. Now, the nightmare strikes back: I have to go back to implementing a connection manager. Tomeu has a point: "How many people you know that understands and enjoys any of mozilla, gtk, pygtk, abiword, X, cairo, etc?". But when did OLPC start doing compromises? And if you have to do a compromise, it's better not to do it at such a critical point like the collaboration in sugar. Here's what I propose: 1) Someone should take the lead at implementing a connection manager and I will actively participate, not just by adapting cerebro's API if necessary, but also with implementing the necessary stubs for the connection manager. But the skeleton must be well understood by the person implementing it! 2) Make provision in both sugar and activities so that there is a clear abstraction from telepathy so that _if_ a better collaboration stack comes along, telepathy won't be "hardcoded" in sugar. This mainly involves documenting the existing calls from sugar/activities to telepathy (and objects returned thereof) and signals provided by telepathy. 3) Get cerebro into joyride which will help a lot with the upcoming multi-hop tests: humans will be operating and updating their XO that participates in the mesh in MIT campus, so I think it is critical to have cerebro in joyride. Am I wrong? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
