[Standards-JIG] In order delivery for xep-0047 ?

[Mickaël Rémond]

Hello,

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  
questionable.
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.

-- 
Mickaël Rémond
  http://www.process-one.net/



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.jabber.org/pipermail/standards/attachments/20061210/f508746a/attachment.html