[Standards-JIG] An XMPP Race Condition most Vexing
jean-louis.seguineau at laposte.net
Sat Oct 28 10:16:38 UTC 2006
Chris, beyond the fact that everyone will appreciate the irony of getting
WS-Transaction "for free" in other protocols ;) I believe you have an
excellent point here: sooner or later some applications built on top of XMPP
will require transactions.
As XMPP grows beyond its initial IM context (after all the RFCs only
describe this aspect) I entirely agree that an accumulation of edge cases
"hacking" is not going to be perceived as a sign of maturity. As you said, I
have the impression a transactional approach to some of the subjects you
mentioned will often help.
I also understand the underlying concern expressed by Matthias of minimizing
the impact of an evolution that could potentially break existing
It seems the growing number of interconnected servers and the experience
gained from observing the associated issues is bearing fruits. I believe
resurrecting some findings or Matthias' proposals into a best practice XEP
(or RFC) for subscription will certainly be a useful addition to our
Beyond this, I also believe that we would have to come up with a transaction
XEP. The two approaches are perfectly compatible, and I don't see why
servers could not learn between them if, for example, transactional presence
subscriptions are supported and use the appropriate protocol, or fall back
on the current one.
Being able to evolve the protocol by integrating additional features that
can be discovered/negotiated is another great advantage of XMPP.
Date: Fri, 27 Oct 2006 17:45:29 -0700
From: "Chris Mullins" <chris.mullins at coversant.net>
Subject: RE: [Standards-JIG] An XMPP Race Condition most Vexing
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
<97B71C0C860DEC40A993AB9F7F0D4335702762 at fattire.winfessor.com>
Content-Type: text/plain; charset="utf-8"
[Chris Thinks XMPP Transactions cool]
[Keeping Presence Subscriptions in-sync across s2s]
> I think I described how this works about a year ago.
> (Short: if you receive a presence probe, but the
> probing sender is not subscribed, then send unsubscribed;
> if you receive a presence stanza you are not interested
> in, then send unsubscribe.)
We can come up with special case solutions to almost all of the problems. I
can certainly code in optimistic concurrency to fix the original problem I
described. No trouble.
The trouble comes up in that we would end up with lots of special case
solutions that could all be solved by XEP-Transaction. This includes areas
such as presence subscriptions, all sorts of MUC and PubSub edge cases, and
most B2B scenarios.
More information about the Standards