On Fri, Feb 19, 2010 at 2:47 AM, Peter Saint-Andre <[email protected]> wrote: > On 2/18/10 5:02 PM, Fabio Forno wrote: >> Tuomas has been quicker than me. I confirm all the points, plus: >> - even xep-184 does not guarantee reliability in a s2s scenario > > There are no *guarantees* of reliability even with IQs. The question is: > how much reliability do you need, and does the use of <iq/> for > notifications achieve that?
But IQs provide at least one guarantee that messages don't: in the case of everything is ok (probably the most common case), you do get and ack of delivery (the IQ result). <message>'s provide none. And in the case where you do have delivery problems or dropped stanzas, you can detect it easily with a timeout. That is better than <message>. >> - I don't see many compatibility issues, since <iq/> delivery is a >> config option which must be turned on > > I think Kev is concerned about compatibility on the client side. The > admin can enable <iq/> delivery on the service but a client might not be > able to handle the notifications because it is expecting <message/> > stanzas, not <iq/> stanzas. In that case the client will presumably > return an IQ error. I must have missed something but I though we where discussion a subscription option that the *client* would enable, not the service administrator. Hence only IQ-delivery supporting clients would ever activate it. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:[email protected] mailto:[email protected]
