mechanisms tied to mesh: "under a tree" collab

[John Gilmore]

> The problem comes from the OLPC marketing that equates "mesh" with  
> "collaboration" which in fact are two independent concepts. What the  
> UI displays as "Mesh Server" should be "Collaboration Server" - it's  
> only needed to mediate if the laptops who want to collaborate cannot  
> talk to each other directly.
> 
> (and btw. you should *not* use olpc.collabora.co.uk anymore which has  
> been switched to a new protocol so you won't see anyone while  
> connected to that server)

Sounds like two TRAC bugs -- the name, and the domain name.  Both are
straight out of 8.2-759.  Will you file them?

> As Benjamin pointed out, the sharing is *not* tied to the mesh. It  
> works just as well if both machines can receive broadcasts (for  
> discovery) and make TCP connections (for actual collaboration). This  
> works in a LAN or between two Qemu instances or even on the same  
> machine running sugar-jhbuild twice (useful for debugging).

Then why can't my two XO's running 8.2-759, both connected to the same
access point, see each other to collaborate?  Neither one shows up in
the other's Network screen.  When I run Write on one, and enable sharing
with My Neighborhood, that copy of Write pops up on its own Neighborhood
screen, but never on the Neighborhood screen (nor in the Frame) of its
neighboring XO.  Is this a third TRAC bug?

(I can never tell whether I really know how to run the GUI for
collaboration, since most of the time it fails, and I don't know if
it's my fault for not following the instructions (do we have some
of those now?), or the fault of bugs in the implementation.)

	John