[Standards-JIG] In order delivery for xep-0047 ?
mickael.remond at process-one.net
Sun Dec 10 17:48:49 UTC 2006
Le 10 déc. 06 à 18:26, Remko Tronçon a écrit :
>> Ordering on the client side is easy and simple.
> It most certainly is not, as explained in depth before. Without
> buffering, a client needs to start inserting messages before other
> displayed messages, which makes no sense. Buffering is a lot of extra
> implementation overhead, requires resources that may not be available
> on the host, and is even impossible because a client cannot know if it
> received all the messages.
I have the feeling that we are not talking about the same thing.
Messages are naturally asynchronous. This means that there is no way
for the client to know which one comes first. Only the server can now
it. To me this is not a place where the ordering behaviour is
On the other hand in-order delivery does not make a lot of sense for
IQs, as the client has the knowledge of how to reorder the stanza.
To make it more concret, here is a real life example: sending a
roster get and then your presence: Is a server really breaking the
spec if the client end up receiving some presences packet before
having received the roster ?
In my opinion, it can be up to the client to wait for the roster,
before sending its presence if this order matter for the client.
Otherwise, the server should propagate the presence as soon as
possible, as asked by the client.
Maybe I am not seeing the problem here, but I feel that if subsequent
actions depend on the result of an IQ, the client should wait for the
result to react appropriately, instead of expecting the server to
sort everything out. That how I understand the IQ semantic: Actions
where result matter.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards