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. >
Tuomas has been quicker than me. I confirm all the points, plus: - even xep-184 does not guarantee reliability in a s2s scenario - in case of high throughput <iq/> delivery has implicit control flow management, as for IBB - I don't see many compatibility issues, since <iq/> delivery is a config option which must be turned on - 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 -- Fabio Forno, Ooros srl jabber id: [email protected]
