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

[Greg Smith]

Hi Rob,

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

I'm not sure I found the place where you recorded that.

Did you by any chance add it to the XO Feature Roadmap?
http://wiki.laptop.org/go/Feature_roadmap

There are some relevant sections there but you can also create your own 
if you prefer.

If you placed it somewhere else you can still add it to the XO roadmap 
and link to it.

FYI there is also an explanation of target scale and use of synchronous 
collaboration here: 
ttp://wiki.laptop.org/go/9.1.0_Collaboration_Requirements linked from 
here: http://wiki.laptop.org/go/Feature_roadmap#Synchronous_Collaboration

If you can document the work needed to achieve those requirements, you 
can create a specification and get as detailed as you like. Or you can 
comment on or change the requirements if you think that is warranted.

Comments or questions welcome, in e-mail or just edit the wiki pages.

Thanks,

Greg S

***********

Date: Wed, 12 Nov 2008 01:48:17 +0000 From: Robert McQueen 
<robert.mcqueen at collabora.co.uk> Subject: Re: [IAEP] [sugar] Sugar Camp 
Cambridge 17-21 Nov To: Bernie Innocenti <bernie at codewiz.org> Cc: 
"Brendan R. Powers" <brendan at resara.com>, Collabora OLPC Team 
<olpc at collabora.co.uk>, Christian Marc Schmidt <schmidt at pentagram.com>, 
IAEP <iaep at lists.sugarlabs.org>, Sugar List <sugar at laptop.org> 
Message-ID: <491A35E1.2040703 at collabora.co.uk> Content-Type: text/plain; 
charset=UTF-8 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