[IAEP] Announcing Fedora Sugar Spin!

[Morgan Collett]

On Wed, Nov 12, 2008 at 18:02, Greg Dekoenigsberg <gdk at redhat.com> 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