[Standards-JIG] An XMPP Race Condition most Vexing

Jean-Louis Seguineau jean-louis.seguineau at laposte.net
Sun Oct 29 09:45:26 UTC 2006


Matthias, this is how I understood you input to the thread. I don't remember
you saying a transaction XEP was un-necessary ;)
I personally feel a 'best practice' document (either XEP or adjunct to the
RFC) would be beneficial to provide an answer to the initial 'race
condition' concern. I have always found that documenting helps synthesize
the discussion threads and provide a better ground for discussion. 

In this particular case, it would have the major interest of highlighting
and make everybody aware of the subscription edge cases (if any). 
If some future context (we cannot foresee everything, can we?) requires a
transactional subscription approach, then we would precisely know were to
start and how it would impact existing implementation.

In the end, both you and Chris have valid points, and documenting them would
allow the proper transition when necessary. 


-----Original Message-----
Date: Sat, 28 Oct 2006 15:02:38 +0200
From: Matthias Wimmer <m at tthias.eu>
Subject: Re: [Standards-JIG] An XMPP Race Condition most Vexing
To: Jabber protocol discussion list <standards-jig at jabber.org>
Message-ID: <454354EE.8040001 at tthias.eu>
Content-Type: text/plain; charset=UTF-8

Jean-Louis Seguineau schrieb:
> 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.

I just wanted to note, that I am not against defining a XEP, that will
allow us to have transactions on top of XMPP, but we do not need to use
them for subscription management (I even think we don't need it for any
of the XMPP features, but it's true that protocols on top of XMPP might
profit if there is a transaction XEP).

If we would require subscription state changes to use transactions, we
would even get into problems if a user wants to remove his account
(which implies removing all subscriptions) but the server of one of his
contacts is gone.


Tot kijk
    Matthias




More information about the Standards mailing list