XOs connected to jabber server AND can link local don't share well

[kimquirk]

Build 581, q2c26

I have three laptops with the same build. I set them up to connect to a local school server mesh; and to 'register' to the jabber.laptop.org server. They are all in the same room, so they can clearly see each other via link local as well.

I booted all three units; two of them can see 8 laptops; the other 2 in the room and 6 others that must also be connecting to jabber.laptop.org.

One of my laptops can only see the other two local laptops; and none of the other laptops. Even though it is also 'registered' to jabber.laptop.org, it doesn't seem to be using that server.

When you try to share in this scenario (connect and memorize, for instance) things don't work properly. All laptops can see the shared activity, can open it, but turns don't happen properly. there is clearly some missing packets somewhere.

I repeated this exact test, but first setting the network manager 'mesh-start' to local; so the laptops never get on the school server mesh or AP. This is the case where the laptops see each other only (like working under a tree). In this case, each of the laptops saw the other two laptops and were able to share a game of connect.

I believe there is a request to turn off link local if there is a jabber server specified. Maybe this is a result of confusion as to whether all the laptops are on link local; or using jabber server.

[sjoerd]

First of all. These things are hard to debug/fix without logs, as we can only guess what happened.

What is clear though is that one of your laptops didn't register correctly to the jabber server and thus wasn't able to see the nodes on the server.. Turning off link-local will only make the behaviour slightly different: If your the only one in a mesh who couldn't reach the jabber server, then you see nobody instead of just the others in your mesh.

What went wrong with the sharing is impossible without more info. Did you share the activity on one of the machines connected to the jabber server or on the one only seeing others on the mesh?

[dcbw]

There are two bugs fixed in this patch, one uncovered by the first.

1) Make the plugins mutually exclusive. When Gabble is active, Salut is disabled, and vice versa. Gabble takes precedence.

2) The changes in telepathy_plugin.py fix 3 bugs uncovered by the first fix 2a) When the gabble plugin is stopped when the machines IP address becomes invalid, the disconnected signal was never emitted, causing (1) above not to work correctly. 2b) self._conn must be cleared _after_ removing contacts, since removing the TP handle from the buddy requires self._conn.service_name to be valid 2c) Calling self._contacts_offline(self._online_contacts) passes that value by reference apparently, leading the code in _contacts_offline() to subtract self._contacts_online from itself, but oddly enough since 'handle' was just an alias to self._contacts_online, handle was also cleared by the -= operation, and therefore was blank when the 'contacts-offline' signal got emitted. Work around that by copying the values instead of passing a reference to self._contacts_online.

[dcbw]

please review and + or - for trial-3 so we can stuff it into builds tomorrow

[morgs]

Dan, I've reviewed your patch and it looks fine as a short-term fix for T3. However we must relook at this after T3 because it's definitely not optimal.

Both plugins are usually started at the same time (when you are on an AP), and Salut normally connects first. The result could be that you see link local buddies appear who might not be on your server - and then they vanish a few seconds later when gabble connects and salut is stopped. I suppose there's no actual harm in that scenario because you probably aren't going to be able to start a link local shared activity in that time...

Also, PS was designed to run both CMs, and could be a lot simpler if we move away from that in the long term, so we need to figure out the long term plan.

[jg]

OK, approved to go into Trial-3.

J5; once in, please retarget this to FRS so that we look at the longer term issues. Most likely it will end up being V1.1 fodder, but you never know.

[jg]

Oh, and reassign it back to dcbw.

[smcv]

(I should note that turning off Salut like this when we have a server connection doesn't do anything to address any concerns you may have about network traffic caused by Salut - as I explained in an email thread a month or so ago, most of Salut's network traffic will already have happened by the time you connect to the server and turn Salut off.)

The fundamental UI problem here is that we don't give the child any indication or control of whether the activity will be shared locally, or on the server, we don't give them that information about activities they can see, and we don't show them whether they and their buddies can see the server or not; but the observable behaviour is inexplicably different, depending on these things.

I realise hiding irrelevant technical details from the children is a goal, but perhaps for 1.1 it would make things clearer if the sharing UI could distinguish between local and server sharing (People Near Me vs My School perhaps?), and add a badge or other scope indication to activities/buddies, or something?

[J5]

package in latest build

[marco]

Per Jim comment...

[tomeu]

I think Eben would be interested in Simon's last comment.

[tomeu]

ups

[gdesmott]

Any reason to keep this bug open? The "one CM connected at a time" seems sane and I doubt we'll consider to change it soon. Objections?