[Sugar-devel] Thoughts on Collab

[Sebastian Silva]

El 24/07/16 a las 05:03, Sam Parkinson escribió:
> I actually don't want to use XMPP for the new collab system.  I don't
> care how nice the library is.  Telepathy isn't the best, maybe pyxmpp2
> or nbxmpp are better.  But xmpp is not the right protocol for sugar.
>
> Say you want to solve problem 2 and have a shared group channel.  You
> could use xmpp, but then every message you send has a huge xml wrapper
> around it adding metadata.  The metedata is useful for an IM
> application, but not very useful at all for Sugar. 
You really should not care about metadata as you shouldn't need to see
it, just parse it. XML is easily compressed.
> So then maybe you use a stream tube over xmpp?  Well (at least for
> telepathy - but it is probably due to the xmpp protocol), you need to
> estabilish a group chat before you can call the stream.  Boom, added
> 200loc and another few round trips before the activity starts
> collaborating.
This is probably a limitation of the telepathy API. Maybe chat ought to
be decoupled from application communication protocols?
> You also say that XMPP is standard, which is nice.  I like standards
> too.  But the way sugar uses xmpp, there is little point to it being
> standard.  "Standard" in Sugar content means you choose between
> ejabberd, jabberd and parsody.  You can't collaborate between Write
> activity and $other_word_processor.  You can't collaborate between
> Bibliography activity and $other_bibliography_manager.  Even if you
> could, that would be based on the "Bibliography Manager Collaboration
> Standard" - not XMPP.

> 1)  A neighbourhood view implementation - a model to discover people
nearby or via the school server
> 2)  A group messaging socket - the backbone for collaboration in
activities
> 3)  A one-to-one file transfer mechanism - used for initial state sync
in activities, "send to" feature in journal, etc

The advantage of using an existing XMPP implementation is (1) and (3)
are probably within reach.
#(2) "group messaging socket" complicates things. What if (1) and (3)
could be made independent of (2)?

> Sugar has generic applications - not chat clients.   We need a generic
> application protocol - not an IM protocol.
One provocative idea: let the shell be/integrate a chat client.
Collaboration/invites could be in the form of URLs handled by plugins.
There are several application protocols for collaboration (e.g.
etherpad). The shell would know what to launch from the URL of the invite.

We should not assume every app will collaborate using the same protocol,
but we should facilitate collaboration nevertheless. Chat is fundamental
even in the same room for sharing gists of text and URLs.

>
> Sebastian raised the point of backwards compatibility for his use
> case.  I think that we can provide a chat bridge no matter the
> technology.  We could also just expose chat activity inside
> traditional dekstop environments, as your work continues to move towards.
Thinking over this even more, I like libpurple/pidgin more than XMPP
because it can connect to all sorts of different backend networks
(including e.g. facebook). The only network that still uses XMPP is
google's and I think it's being phased out. It also supports link-local
XMPP.