On Wed, 2008-11-12 at 20:23 +0200, 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.
I'm only here to break the thread against fedora-announce-list. Ignore and move on... ;-) -- Paul W. Frields gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://paul.frields.org/ - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
signature.asc
Description: This is a digitally signed message part
_______________________________________________ IAEP -- It's An Education Project (not a laptop project!) [email protected] http://lists.sugarlabs.org/listinfo/iaep
