[Sugar-devel] [sugar] XO identity shared via Browse
robert.mcqueen at collabora.co.uk
Thu Dec 4 17:34:48 EST 2008
Ivan Krstić wrote:
> For those just tuning in, the whole story of Jabber on the XO
> has basically been colorfully fucked, as has that of the entire
> collaboration stack. I suggest further proposals of actually using
> Jabber for anything wait until the basic XO implementation gets to the
> point where IRC was 20 years ago -- namely, working.
I really don't think these kind of comments are productive for anyone.
I'm pretty fed up of discussions about collaboration which take the
format of stating that things are broken, hypothesizing about new
approaches which might work better, and ignoring what Collabora has done
I know we've made mistakes with what has been implemented but we can
operate e-mail clients reasonably well and we're not fucking idiots, so
I'd like to think it's worth communicating with us so we can explain the
rationale behind what we've done. Then maybe we can actually cooperate
and correct any misapprehensions and hence make the appropriate
corrections to our implementation, rather than just talking across each
other all the time.
However, I'm not interested in participating (therefore I have not done
so) in participating in discussions about collaboration on Sugar which
a) ignore everything we've done so far, and b) contain fallacies such as:
* Given a working IPv6 network, we...
* Given a global DNS hirachy of school servers, we...
If these presumptions were true (and considering XMPP only because
multicast is a complete fuckup on the XO mesh network), then what
we've implemented would work a hell of a lot better than it currently
does. There's nothing about XMPP that will prevent it from "actually
working", except for certain errors we've made in our implementation:
1. Abusing rosters on the XMPP server to achieve mutual visibility,
which scales poorly and destabilises the XMPP server.
2. Sending XMPP data in-band is slow as hell.
3. The tubes APIs are hard to use.
4. The JIDs are allocated in a user-opaque fashion.
5. You can't transfer files.
The reasons for these errors (respectively)
1. The UI had no way for controlling visibility, and no discussion
about how to do it ever terminated, so we made a hack which stuck
way longer than it should've done. We didn't have a lot of timeline
or requirements to go on, so our decisions for what to prioritise
were underinformed, and the starting of deployments with what we had
really took us by surprise.
2. We were under-resourced and prioritised implementing the tubes API
for others to use over implementing it in a performant fashion, and
then we continued to be under-resourced and chasing other issues
like why multicast worked so badly.
3. We didn't have time to think a lot about how to make it easy, and we
didn't have any requirements, so we had to pick some stuff and hope
that activity authors would push back. We understand D-Bus well, so
a D-Bus tube seemed like a really good idea to us to expose a
multi-participant primitive which had some routing capabilities, but
didn't mean using multicast in the application. Stream tubes let you
share arbitrary socket apps with no modification and a tiny bit of
Telepathy glue code, but, you know what? POSIX sockets aren't /that/
easy to use either. Distributed systems are actually hard.
4. We were given vague requirements about ensuring consistency of
identity across different collaboration mechanisms using the XO's
key, and although the exact reasoning escapes me now, the
constraints of the legacy (before we turned up) presence service API
meant the only way we were able to reconcile this with XMPP was to
make the key hash part of the JID to avoid the need for any
additional communication to verify identity of buddies. But we were
told that key hashes weren't unique enough, so in the face of
apparently unsatisfiable requirements we just left this one to focus
on other things instead.
5. We were told that live collaborative applications were more
Our plans for fixing them (respectively):
1. Martin and the other XS guys have already done great work fixing up
ejabberd to be more reliable even in this odd configuration, and
we've written Gadget, the XMPP server-side component which takes
care of indexing and searching buddies and activities which are
available on your server. Total mutual visibility no longer has to
be enforced on the server, and the XO (code, at least) can opt in or
out to publishing its activities and presence, as with normal XMPP.
2. We've basically fixed this now, Gabble has code for using the
standard XMPP SOCKS5 bytestreams to implement stream tubes using
peer to peer connections. It can soon make use of a relay component
on the XMPP server to aid NAT traversal, and falls back to in-band
bytestreams. It's harder on D-Bus tubes because they're one to many
and D-Bus has message ordering guarantees which we currently rely on
the XMPP server to enforce for us. We can revisit this later after
file transfer works better, or work on the activities we have to
favour stream tubes (and hence inherently P2P traffic) over D-Bus
tubes, or just use them for light synchronisation traffic (like send
next/prev D-Bus messages, but make a stream tube or a file transfer
for dumping the initial document).
3. Some people have had great ideas at building simpler primitives for
simpler use-cases, like the shared object state python classes by
Ben Schwartz, but unless you do something roughly turn-based or rely
on a single master, it's still not very easy to keep shared state
synchronised with multiple distributed participants. Distributed
systems continue to be quite hard. Most journal sharing and
datastore versioning discussions never quite seem to terminate for
this reason too. :P
4. We've given up on that, in favour of using the JID as the unique ID,
so provided the school server actually has a unique DNS name, we're
all set. We can expose different contacts on different protocols as
possibly different buddies, then delete a whole load of bullshit
(most of presence service, we hope), and we can revisit the security
requirements once stuff is working better and the XMPP folks have
moved further on how their end to end crypto should work (or join
forces and move it with them).
5. We were told recently that transferring files was important too, so
we've implemented it in Telepathy, starting with the Salut backend,
and soon in Gabble too (using the XMPP file transfer standards).
Currently Collabora is working on fixing these issues as pro bono work,
because we believe that SugarLabs is worth supporting and we admit that
we've made some mistakes and we'd like to fix them. However, every time
people continue to criticise and ignore us, it gets more and more
tempting to just wash our hands of the whole thing and just give up.
So, given we've got some existing code which can actually work, and a
plan of action to make it work better, we'd really appreciate if people
actually talk to us with coherent criticisms and suggestions for
improvements, rather than just at best ignoring us, or at worst
criticising us, and somehow hoping that a fairy will descend and make
these problems go away.
> Ivan Krstić <krstic at solarsail.hcs.harvard.edu> | http://radian.org
1: Red Hat were already using multicast when Collabora were engaged, so
it was handed to us as a requirement. We quickly identified that it
worked very badly on the XO mesh, so we filed a ticket, which was
ignored for almost an entire year, at which point people turned around
and said "OH MY GOD, YOU'RE NOT USING MULTICAST ARE YOU? YOU FOOLS!".
Anyway, screw that, if the XO mesh honestly can't be made to do
multicast, and you can't/won't ever fix it, then some kind of
higher-layer hack like Cerebro seems a reasonable workaround, and we
showed it was entirely possible to implement Telepathy APIs on top of
Cerebro. However, outside of the OLPC project, working around the XO's
broken networking hardware is of little to no interest to Collabora and
the Telepathy project.
Robert McQueen +44 7876 562 564
Director, Collabora Ltd. http://www.collabora.co.uk
More information about the Sugar-devel