[IAEP] [sugar] Sugar Camp Cambridge 17-21 Nov

[Robert McQueen]

Hi Bernie, Brendan,

Bernie Innocenti wrote:
> Brendan R. Powers wrote:
>> I would like to propose a discussion on making the collaboration a bit
>> more standards compliant. The idea would be to get sugar to function
>> more like a standard jabber IM client, as well as using existing
>> standards in place of some of the custom solutions used now (xmlrpc
>> instead of dbus perhaps?). I would also like to talk about using the
>> colaboration API to talk to external services not on the jabber
>> network(a moodle server for instance). As well as a possibly a few
>> API changes to make these sorts of services easier to access for
>> activity developers.

Switching to XMLRPC?! This seems like some massive sidestep which would
break the existing stuff as well as preventing any code sharing between
Telepathy apps on Sugar and Telepathy apps on any other Linux platforms.
D-Bus and the Telepathy APIs are the emerging standards for accessing
real-time communications functionality on Linux desktops and embedded
devices. It's already in GNOME in the Empathy client, as well as part of
the GNOME Mobile platform, so Nokia's Maemo and Intel's Moblin
platforms, and there's ongoing interest in using it in KDE which we hope
to push forward at the combined Akademy/Guadec next summer.

That aside, the rest of what you say matches up very well with a lot of
the ideas we've had for improving collaboration in 9.1:

 * I've already filed a bug and spoken to Eben to get a UI in Sugar for
   seeing your JID, entering other people's, and doing authorisation
   requests. This allows you to deal with people from outside your XMPP
   server, so basically behaving as a real Jabber client (the Telepathy
   backends are entirely usable like this - my day-to-day IM client is
   Empathy).

 * I also proposed to gradually reduce the sugar-specific abstraction
   that the presence service does, so activities interact directly with
   the Telepathy backends more. We can implement the current Sugar
   presence service API with client code in the sugar library, but it
   can talk directly to Telepathy behind the scenes. This means:
    - fewer layers of abstraction - currently Presence Service does a
      load of caching and re-emitting of information through the curious
      D-Bus API we inherited when we started work on this way back... :)
    - any other Telepathy backends can be added and used for chatting,
      calling and file transfers on other protocols (we have IRC, SIP,
      MSN, AIM, ICQ, Yahii, and anything else supported by libpurple)
      without having to mangle presence service to do things it wasn't
      really intended
    - the APIs relied on by activities then become the same as Telepathy
      apps on other platforms, allowing code sharing in both directions
    - the APIs are the same in terms of documentation and utility code
      which can be enhanced in telepathy-python (and equivalent -glib
      and -qt4 libraries) to the benefit of all

>> Having a standards base and flexible collaboration framework that
>> extends beyond the sugar ecosystem offers some very interesting
>> possibilities. I would also like to discuss some of the jabber
>> scalability problems, as well as how we manage grouping students
>> into classes, and collaborating with other schools over the
>> internet.

Sure, we've done a lot on enhancing scalability recently with the Gadget
XMPP extension to take care of indexing buddies and activities. Groups
and collaborating with other schools are the next really exciting
avenues for this work.

>> If people thinks this is a good idea for discussion I will
>> add it to the wiki.
> 
> By all means, yes!

I already added some of these above things to the roadmap wiki page as
things to try and improve in 9.1.

> Make sure you also involve Martin Langhoff (school server architect)
> and either Morgan Collet or Robert McQueen (not sure who of them worked
> more on the Sugar/Jabber integration).

Well, Guillaume, Daf and previously Simon did most of the actual legwork
on the actual Telepathy backends which speak Sugar uses to speak XMPP,
and the more recent work on the Gadget component to aid scalability on
school servers. We'd be happy to send someone over to chat about this
kind of thing with the Sugar devs but not only have we not been invited
to participate at all, we've not heard anything back from OLPC about
renewing our contract for several weeks now. :(

Unless the situation changes before too long then we'll have to start
assigning our developers onto other projects, and our involvement will
be reduced to upstream development/maintenance of the Telepathy
components (although this is not all bad, we're doing file transfer and
peer-to-peer tube connections at the moment, which are both great for
Sugar), and some basic maintenance and support on the Sugar-specific parts.

> Cc'ing them all :-)

Added olpc at collabora.co.uk to catch all of our OLPC team, for now. :(

Regards,
Rob

-- 
Robert McQueen                                 +44 7876 562 564
Director, Collabora Ltd.             http://www.collabora.co.uk