On Tue, Jun 10, 2008 at 19:05, Polychronis Ypodimatopoulos <[EMAIL PROTECTED]> wrote: > 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?
I started working for Collabora on the presence stack just over a year ago. I'll try to give some context to the presence stack architecture based on my experience since then. Presence Service (PS) predates the use of Telepathy. When I started on this, PS was maintained by Dan Williams (Redhat). It was then maintained by Simon McVittie (Collabora) and then myself when Simon switched projects. When I left Collabora, Guillaume Desmottes (Collabora) took over as primary maintainer, although I continue to contribute. PS has a certain amount of cruft in the codebase from before Telepathy was integrated. There are some design aspects that would be politely considered "interesting", such as the fact that there are two entirely different mechanisms for tracking who is in an activity (so we can show the buddies clustered around the activity icon in Neighborhood view) - before we join a shared activity we need to track who's in it by their announcements of their activities, but when we are in a shared activity, we can see the other participants directly. When joining an activity, we switch from the one mechanism to the other. For your interest, outside of Sugarland, the component in the Telepathy architecture which is most directly equivalent to PS is called Mission Control (see the diagram on http://mission-control.sourceforge.net/). When I started with Collabora, activities contained a lot of Telepathy code. In fact, Connect was the only collaborative activity, and it was our test case for the implementation. A fair amount of my efforts with respect to the presence stack have been to simplify the API or collaboration mechanisms available to activity authors. This has been done by pushing the Telepathy functionality into PS where possible, or sugar.presence which is the client to the PS D-Bus API for python activities. At this point, there remains code in activities to deal with the setup of Tubes. In a further development cycle, after 8.2 / Sugar 0.82, I plan to simplify that further so that all collaborative python activities get a D-Tube set up automatically, and don't need any boilerplate for that at all. I hope this gives some explanation of why there is Telepathy code in activities. Even with all the current boilerplate removed, it should still be possible for activities to interact directly with Telepathy should the activity author want to do something not provided by the framework. Regards Morgan _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel