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

[Mridul]

Maciek Niedzielski wrote:
> Mridul wrote:
>   
>> Ian Paterson wrote:
>>     
>>> Since the intention has always been for in-order delivery, either we
>>> need to tighten up the wording of the RFC a little to remove any
>>> possible doubt, or we need to agree a radical change to XMPP to allow
>>> client implementations to reorder the instant messages they receive.
>>>       
>> Message ordering is very simple to handle at clients if required :
>> timestamps, seq numbers, etc - not sure why this should even be pushed
>> to the server.
>>     
> Ordering by timestamps does not meet IM needs for the "presentational"
> reason: The client doesn't know if it has all previous messages already,
> so it cannot wait for the missing messages: it has to display them as
> they arrive. So dynamic reordering at client side would require
> inserting delayed messages somewhere in the middle of the chat log,
> which may be confusing and hard to notice. And now imagine you just
> logged in and 20 offline messages appear in front of you this way: maybe
> it would look cool at the first time, but I wouldn't like to see it again.
>
>   

You are quite right, and I do agree that there are potential problems 
for out of order delivery of normal chat messages.
But then, the possibility of this happening for normal chat messages 
under low volume client connections, as I tried to explain in some other 
response, is negligable.

Applications which use xmpp as middleware, which need to strictly 
enforce order, can always build higher layers of abstraction on top 
which enforce pessimistic order semantics.

Regards,
Mridul