[sugar] Couple of questions

[Robert McQueen]

Dan Williams wrote:
> First off, the problem with the current implementations of presence in
> most everything, including Telepathy & Galago, is that they are geared
> towards traditional notions of presence.  By which I mean "Is Tommy
> online?  What capabilities does Tommy have?"  That's about it, as far as
> I can tell from the Telepathy D-Bus API and what I've read about Galago.

Telepathy borrows heavily from Galago's ideas of presence. In both there
is the idea of your presence being a set of potentially multiple
statuses, so you can be online as well as participating in various
activities. Both Telepathy and Galago statuses are also arbitrarily
extensible using key/value arguments. I don't think it'd be hard to map
between either and the presence API.

> In our case, we have an expanded notion of presence beyond whether or
> not a buddy is simply present and whether or not they can do video chat.
> In our model, each buddy provides certain services (in the mDNS/ZeroConf
> sense of the word), for example a chat service or a voip service, or an
> activity service.  Advertisement of an activity service determines a
> person's participation on the activity.

Don't worry about this, it's very easy to imagine implementing this on
top of Telepathy, or adding an interface for it - Telepathy's design is
very extensible for exactly these reasons.

> This matches up much more
> closely to Jabber/XMPP's Service Discovery specification, except that
> instead of jabber servers advertising services like directories and
> conference rooms, the _buddys_ are advertising their own services.  Or,
> if you prefer, it's much more of a ZeroConf view, if you include
> publishing.

Service discovery results are perfectly valid on any jabber ID (be it a
room, or a server, or a contact), but are not meant to change after
being queried. What you want is much closer to entity capabilities -
these are embedded inside your <presence> node, and refer to cachable
sets of service-discoverable features, and one is able to change which
sets of features are available on the fly.

> We're not trying to combine and reconcile presence attributes from users
> of different accounts and services and match that up to stored
> information, which is what I understand is one of Galago's purposes.
...
> We also need to do this sort
> of stuff without a central server, on the local mesh, where mDNS works
> great and provides exactly the model we want.  Perhaps that could be
> done with a plugin for Telepathy, but I'm not sure what the benefit of
> adding Galago on top of all this is, if we're just going to have to do a
> bunch of processing aside from Galago too.

I don't think a bunch of processing aside from Galago will be necessary,
but what Galago does offer is the seamless coalescing of information
about buddies from a number of sources. The idea is that multiple
sources provide information (eg your address book, any IM account(s) you
have on, etc) and everyone stores or copies it to Galago's person model,
which can be queried, used and updated from anywhere else. On a desktop
deployment of Telepathy, Galago is pivotal in re-assembling the concept
of people which you lose by splitting up the backends into seperate
processes. On Sugar, if you only ever have one account on one backend
then Galago isn't necessarily a big win, so I'd agree to some extent.

> Dan

Regards,
Rob