> Right. Ordering is important enough that I think this issue deserves more > than one sentence in the RFC. > > It seems our choices are: > > 1) "Entity" is a Full JID. Resource locking (RFC 3921) and MUC (XEP-0045) > need repairs, or we just live with their problems and try not to repeat them. > > 2) "Entity" is a Bare JID. Everything works as Jeremy Himself intended.
I think it needs a bit more explanation. I guess not everybody (myself for example) knows what Jeremy Himself intended. Specifically, the Bare JID may have a few connections to the server and there might be packets addresses to different resources. What the above sentence means in this context? > Can developers of various servers describe their current ordering policies? > It would be interesting to see just how the spec has been interpretted so far. I tried a few different approaches. It is quite easy to switch between them in the Tigase. In order processing per TCP/IP stream, per sender address, per received address (not bare JID though, I will try that next time I run tests). Even though it appears to be working correctly in the test system, nothing seems to guarantee 100% packet in order delivery in some border cases unless you switch to single threaded mode which is not feasible. Artur -- Artur Hefczyc http://www.tigase.org/ http://artur.hefczyc.net/
