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?
My take:
1. Whatever default policy we choose will be wrong for a significant subset of users.
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.
--g
On Wed, Nov 12, 2008 at 18:02, Greg Dekoenigsberg gdk@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:
- 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.
- 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.
- 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
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 gdk@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:
- 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.
- 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.
- 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
On Wed, 2008-11-12 at 20:23 +0200, Morgan Collett wrote:
On Wed, Nov 12, 2008 at 18:02, Greg Dekoenigsberg gdk@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:
- 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.
- 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.
- 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... ;-)