On 14-Sep-2009, at 18:56, Peter Saint-Andre wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 8/29/09 6:52 AM, Fabio Forno wrote:
On Sat, Aug 29, 2009 at 2:11 PM, Brian Cully<[email protected]> wrote:
Another thing: I think that the option of delivering items via
<iq/>
has already been discussed many times, but I don't find any
reference
I don't remember seeing this. All I remember is retrieving
items by
iq, which is described in XEP-0060 s6.4.
Perhaps it was discussed in the summit ad Bruxelles, but since we
were
split in small groups on different topics I missed the discussion.
The
fact is that when you want reliable delivery it is much easier to
rely
on direct acks than waiting for possible errors. Since it is all an
internal thing we're going with <iq/> delivery, I was just wondering
if it makes sense to make it a standard delivery option in node
configuration.
Yes, I think it makes sense to add this. However, the pubsub service
would need to know the full JID of the recipient. How does it behave
if
it does not have that information? Does it not send a notification?
Does
it spool up notifications for when it next knows a full JID for the
subscriber?
If you were to allow delivery via IQ I think you'd have to mandate
subscription by full JID only. I can't figure how the pubsub service
would suss out a full JID from a bare without doing unseemly things.
In any event it would not be fun to implement at all.
Further: how much core delivery logic are we forcing onto the pubsub
service?
In the case of IQ delivery, if the problems with bare JIDs can be
solved somehow (including not allowing them to subscribe to nodes
configured to deliver via IQ) then any existing XMPP fabric should be
able to handle the routing normally, and the pubsub service would only
need to handle IQ related errors in addition to their current chores.
All that being said, I'm not thrilled with the idea of IQ delivery.
I'd think if you needed something like this then you should use some
kind of message delivery verification (I know, I know, we've been over
this a million times), presence based subscriptions, or something
similar.
-bjc
