[+cc: Sugar] On Thu, Nov 20, 2008 at 02:26, Martin Langhoff <[EMAIL PROTECTED]> wrote: > From a collaboration POV, my top priority is to sit down with > Guillaume while he's here and understand their (Collabora's) thinking > about Gadget and other reasons why the presence service might be evil > that I don't know yet -- I seem to be on my way to succeed fixing the > evils I know about in it ;-)
Since Guillaume mentioned "Presence Service must die!!1!" there seems to be some confusion about what Presence Service is, and why Collabora proposed to replace it. Presence Service was (IIRC) originally maintained by Dan Williams at RedHat, then by various Collabora people including myself, and now by Guillaume and myself. Practically nobody outside of this group has any idea how Presence Service is implemented, and the depths of its "evilness". Presence Service is not ejabberd or any component running on the XS. http://wiki.laptop.org/go/Presence_Service contains a diagram showing where PS fits into the Sugar stack. It is a layer of abstraction between Sugar and the two Telepathy Connection Managers we are currently using, Gabble and Salut. It is responsible for: * Connecting one or more Telepathy Connection Managers * Doing account-related stuff like setting your Jabber ID to some unintelligible machine-readable strings to ensure you have a unique identity regardless of your mutable identity like nick and colors * Providing a D-Bus API for non-Python activities * Creating the plumbing for shared activities including a "room", a Telepathy text channel, a Tubes channel, etc. * Tracking, and caching, who you can see and which shared activities you are aware of, and who is in them It was also designed for plugging in encryption and digital signature, which are to some extent already implemented in XMPP, which would provide for confidentiality and authentication. This has been delayed until (a) presence and collaboration as they are now, actually work well, without the burden of additional complexity and CPU demands, and (b) an actual security requirements analysis has been done to determine what we should implement and how. Presence Service is specific to Sugar. It is a nightmare to maintain, since it contains cruft from before Telepathy was added to the stack, and some really weird design decisions were made. Nobody else can or will use it. There is an equivalent component in the non-Sugar Telepathy stack, called Mission Control - developed by Nokia for account management (and other things) in Maemo/ITOS. Mission Control is also used by the Empathy desktop IM/V/VoIP client in GNOME. Collabora have therefore suggested replacing Presence Service with a combination of Mission Control and moving functionality up into sugar-toolkit and the activities themselves, so that everything is talking Telepathy and not some arbitrary abstraction of an abstraction framework. As far as public discussion of this goes, I think it is sufficient to note that we have component in the Sugar stack that is inefficient, difficult to maintain, impossible to share with other projects, makes the actual status of presence unnecessarily opaque to things that need to know, and is a blocker on much of the work we have in mind to improve presence and collaboration reliability and scalability. To do any work on this functionality in Sugar, we need to invest. We can either invest in short term band-aids and long term insanity, or we can invest in improving the platform and leveraging others' efforts in solving similar problems. Hope that helps, Morgan _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
