Thanks for the detailed analysis, Morgan. Much appreciated. --g
On Wed, 12 Nov 2008, Morgan Collett wrote: > On Wed, Nov 12, 2008 at 18:02, Greg Dekoenigsberg <[EMAIL PROTECTED]> wrote: >> >> On Wed, 12 Nov 2008, Bill Kerr wrote: >> >>> Meaning what, exactly? Can you be more specific? >>> >>> Well, it's meant to be possible for collaboration to work out of the box. >>> This did not happen with Wolfgang's Live CD converted to USB keys. >>> >>> Someone reported earlier on this list that collaboration did work from >>> USB keys on a Ubuntu network >>> >>> from morgan collett: "Link local presence should "just work", but I've >>> never used the LiveCD images." >>> >>> At any rate Morgan asked us for some files and after they were sent >>> reported back: >>> >>> from morgan collett: >>> "Thanks for the logs. presenceservice.log shows that salut >>> (LinkLocalPlugin) starts up successfully but doesn't detect anyone on >>> the local network. gabble (ServerPlugin) repeatedly attempts to >>> connect to a jabber server but fails - nevertheless salut is running." >>> >>> After this one of my students built a jabber server and we could do >>> collaboration through that >>> >>> I was hoping that with the new Fedora USB key we could do collaboration >>> out of the box, meaning without using the jabber server >>> >>> All I tested with the new Fedora USB key was trying to connect through >>> Chat but that didn't work >>> >>> Let me know if you want more information or diagnostic files again - I can >>> look up the details or ask joel for help if needed - just tell me exactly >>> the information you need >>> >>> a bit more detail of the history here: >>> http://xo-whs.wikispaces.com/connectivity >> >> Ah, right. >> >> So what we have is a complex policy issue, but it boils down to this: >> >> With whom should a new Sugar user be "collaborating" by default? >> >> Many options here. Machines on the local mesh subnet? Should there be a >> default jabberd server? Should there be discoverability of all jabberd >> servers in the world? > > A quick explanation about the built-in policy of > sugar-presence-service: On startup, telepathy-salut is started for > link local presence and collaboration (avahi etc). If network manager > reports a valid IP address, then telepathy-gabble is started to try > and connect to the configured jabber server. Until such time as gabble > connects successfully, salut continues to be the presence mechanism. > When gabble connects, salut is stopped and presence is done via the > jabber server. > > That policy is in the code base and is not configurable without modifying > code. > > OLPC XO releases ship with no jabber server configured (and in the > past, with a non-existant jabber server like ship2.jabber.laptop.org) > since our ejabberd setup falls over with more than about 150 people on > the server. (That is a more complex discussion which we have had > several times - ask me if you want the explanation. A 9.1.0 feature > should improve that.) > > Discoverability of jabber servers is unfortunately a good way to kill > them all, with the above limitation. Servers listed on > http://wiki.laptop.org/go/Community_Jabber_Servers are regularly down > for long periods because of this. > > With Sugar 0.82 it is easy to set a jabber server in the control > panel, but it should only be done by informed decision: Jabber servers > should only be run for specific communities, like an XO community in a > specific city, or a for a specific school, etc. We do not have an > access control mechanism to restrict that, but when people go "Oh > cool, let me try that one" at random then it denies service to the > intended users of the server. > > Debian Lenny and Ubuntu Intrepid ship the required patches in their > ejabberd packages, and there are rpms available as part of the XS > project, for those who want to set up community servers. > >> My take: >> >> 1. Whatever default policy we choose will be wrong for a significant subset >> of users. > > The way OLPC builds ship, two XOs on the same mesh channel or the same > AP will see each other, out of the box. There's no server than can > handle being the default, so it's simple: ship with no server > configured. > > That relies on link local presence/collaboration actually working: if > it isn't, you something to fix, since it works fine on OLPC 8.2.0 and > other distros. > >> 2. Collaboration must be one of the "killer apps", and even if it doesn't >> work out of the box *trivially*, it should be possible for users to iterate >> through the possible collaboration network options with miminal pain. >> >> 3. Can we discuss this at next week's Sugar conference? To me, answering >> these questions is worth a day or more of face time. > > Unfortunately I won't be there in person but I'll try to participate > remotely if time zones permit. > > Regards > Morgan > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
