On Fri, 25 Jun 2010, Matthew Wild wrote:
On 25 June 2010 10:02, Dave Cridland <[email protected]> wrote:
On Thu Jun 24 21:52:22 2010, Matthew Wild wrote:
On 24 June 2010 21:33, Justin Karneges
<[email protected]> wrote:
It's a common problem to join a muc that already thinks you are joined,
and
then the presence you send is interpretted as a mere status change
rather
than a full join. Then you don't get the room roster, history, etc.
Kev
informs me that the <x xmlns="http://jabber.org/protocol/muc";> element
(hereby referred to as "the muc element") is supposed to solve this
problem.
You include it only on join stanzas, but not on status change stanzas.
This
way, if a muc sees the element but thought you were already joined, it
can do
a proper rejoin.
Yes, Prosody has had this code since the early days, however we
currently have it commented out due to Google Talk's issues. Gajim
also included the element on nick changes, but we ensured this was
fixed, and added a workaround for it.
But there's little way we can work around Google's oddity (well
technically there is, but none I'd be happy with releasing).
There is, in fact, a workaround in M-Link, too, in as much as it's possible
to strip out the XEP-0045 control element on inbound presence from a domain
before the processing code ever sees it. I'd be loathe to put that into
production.
That's not actually possible on its own, unless you know which domains
are Google and which aren't. Our "workaround" was to detect this based
on the SRV records for the domain - then we set a flag for that stream
to say that it repeats presence, and our MUC component disables the
rejoin logic for stanzas received over that stream. That is some
workaround, though I don't see why it wouldn't work.
You'd be better off detecting this based on behaviour, rather than
particular strings appearing in the SRV records, as Google's
implementation is probably not the only one doing this. Eg, if user(s)
from domain foo consistently send a directed presence every X minutes over
~30 minutes, assume that the server hosting the domain is broken in this
regard and trigger the workaround mentioned.
But don't be coy about this - this is an interop bug, not a mere oddity.
While I don't see anything in the spec suggesting that directed presence
should be repeated, I admit there's nothing in the spec about it not being
repeated either, so we either have a bug in the spec (if Google insist the
spec allows them to do this) or a bug in GTalk (if they admit they
shouldn't). Either way, it needs resolution.
Yes, agreed.
I'm actually wondering whether this replay every 5 minutes is from
gtalk-the-service or gtalk-the-embedded-in-gmail-web-interface-client.
There's actually a (3), which is "If you replay directed presence, then add
a delay".
This sounds like a good solution, if they really want to carry on
doing this (does anyone know why they do?).
If it's gtalk-the-embedded-client, then the replays are most likely the
client's keepalive logic simply running through the list of everything
that it has sent a presence to (and resending the exact stanza it sent
originally). If that's the case, then the onus is on
Google to have the client drop the muc element when it stores it for
later use with the periodic keepalive.
--
Bruce.
