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 and why. 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[1] 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 important. 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ć <[EMAIL PROTECTED]> | http://radian.org Regards, Rob 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 _______________________________________________ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar