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

Fabio Forno fabio.forno at gmail.com
Fri Feb 19 09:25:38 UTC 2010

On Fri, Feb 19, 2010 at 3:47 AM, Peter Saint-Andre
<stpehttp://www.goshtube.com/404ter@stpeter.im> 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?

That was my point: in federated scenario there is no such thing like
general reliability, but options that can make your solution reliable,
accordingly to your definition of reliable and your application
constraints. If for you reliable means delivery to the correct
resource IQs are reliable. If you can keep items in the node until you
receive an ack from all the subscribers IQs are still the best option,
otherwise it's better let the offline storage of servers handle the
this kind of buffering.
Imho seeking for a general solution for reliability is a waste of
time, it's better to offer a set of options and then let developers
chose which one fits better

>> - 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, but most likely that client won't be able to handle the event
payload too, since usually client must have ad hoc handlers for pubsub
notifications. Moreover IQs are already used in several solutions (we
do, Buddycloud people do) and a documented feature is more likely to
be implemented by clients than an undocumented one ;)

>> - 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.

Just a general consideration: IQs need presence subscriptions with the
pubsub service, many application we are developing need them, pubsub
components I've tried usually miss this feature (they are server
plugins which exploit the internal session table of the server, but
this works just for local users); so IQ delivery could be an incentive
for supporting presence subscriptions with the pubsub service.


Fabio Forno,
Bluendo srl http://www.bluendo.com
jabber id: ff at jabber.bluendo.com

More information about the Standards mailing list