On 2/18/10 5:02 PM, Fabio Forno wrote: > On Fri, Feb 19, 2010 at 12:10 AM, Tuomas Koski <[email protected]> wrote: >> >> I have to admit that I have forgotten these use cases too. How ever >> here are my reasons why I'm sending events in IQs: >> * to be 100% sure that the events don't go to offline storage >> * To have "acks" without implement XEP-0184 Message Receipts or similar >> * I'm connected with a JID with multiple resources (/a and /b for >> example). I want to send events only to resource /a. When the >> resource /a for some reason disappears some servers starts to route >> message stanzas sent to resource /a to resource /b.
But you could do that with XEP-0079. ;-) I'm joking. Those do seem like valid reasons. > 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? > - in case of high throughput <iq/> delivery has implicit control flow > management, as for IBB Yes, that's a nice side-benefit. > - 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. > - yep, it works just with presence subscriptions to the pubsub nodes, > but one of the features I usually miss in standard pubsub services for > real applications is a decent handling of presence subscriptions I'm not sure how that's connected to <iq/> delivery. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
