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

[Brendan R. Powers]

Hi,

I did not mean to suggest ripping out telepathy and dbus, and replacing it with xmlrpc. My thought on the subject was that dbus may not be well suited for network communication because it's a binary protocol. The problem comes in when the application on the other side of the tube does not speak native dbus(php or java apps). I think xmlrpc may be a good alternative in this case because it is very simple, and its an established rpc standard on the web. Its also a XMPP standard(XEP 0009). There are several ways you could introduce this without breaking everything in the process, for instance, a new tube type could be created to support xmlrpc, like there is for dbus. That way, applications could choose to use the rpc mechanism that made sense for that app.

I hope to provoke a discussion on how we can leverage the technologies of telepathy, jabber, and other web standards to make sugar a fantastic platform for collaboration with activities, as well as web services.

I'm sorry I didn't make these points clear earlier, as I don't plan on ripping large chunks of sugar's existing infrastructure to peaces:-) I look forward to having a very interesting discussion with everyone next week.

----- "Robert McQueen" <robert.mcqueen at collabora.co.uk> wrote:
> 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