[sugar] Presence Service

[Morgan Collett]

[+cc: Sugar]

On Thu, Nov 20, 2008 at 02:26, Martin Langhoff
<martin.langhoff at gmail.com> 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