[Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)

Peter Saint-Andre stpeter at stpeter.im
Fri Feb 19 02:47:12 UTC 2010


On 2/18/10 5:02 PM, Fabio Forno wrote:
> On Fri, Feb 19, 2010 at 12:10 AM, Tuomas Koski <koski.tuomas at gmail.com> 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/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100218/f65eba18/attachment.bin>


More information about the Standards mailing list