Jumping into this thread at random, I hope to address some of my concerns towards iq-based notifications in XEP-0060.
On Thu, 2010-02-18 at 19:47 -0700, Peter Saint-Andre wrote: > 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. Even though Peter mentioned this jokingly, I'm very curious about /why/ Advanced Message Processing (XEP-0079) hasn't been picked up. I think it potentially addresses some of the mentioned issues and is already mentioned in section 12.5 of XEP-0060. It allows an entity (like a pubsub service) to mention that it wants a message to be dropped or have the recipient's server send back notifications or errors based on a set of rules. This can be based on where it would be delivered to, or time (timeout), or future extensions. I can think of some reasons AMP hasn't been picked up: 1) AMP requires the session manager (or equivalent) to read into the stanza beyond just the attributes on the outer element (to, from, type). 2) AMP is incomplete, badly architected 3) Does not actually address all issues IQs would solve 4) AMP is not implemented by servers and/or pubsub services For 1, I'd love to see some opinions. I think ejabberd has implemented AMP. We are also have some other proposed extensions that do delivery magic, like SIFT, so this might actually not be really hard to do. I just don't know. For 2, I'm curious for opinions, too. I don't believe it is inherently bad, and like to resolve whatever issues are there. For 3, let's figure out those use cases, and see if it makes sense to address that in XEP-0079. For 4, chicken/egg of course, but adding support for this in Idavoll is probably not very difficult and something I would look into if desirable. AMP doesn't address lost messages or iq responses, but I believe that if you need that kind of reliability, you probably need a transactional system with n-phase commits anyway. I do believe that it addresses the same use cases as iq-based notifications would, plus more, even though not now. > > 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. >From a pubsub service point-of-view, this is actually not a very nice property. It requires the whole notification delivery mechanism to implement delivery queues with retries (for stuff that might actually have been received all right) and back-off algorithms. Basically turning a fire-and-forget system into a store-and-forward one. > > - 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. As mentioned before, this is not so much a problem if the client needs to turn it on anyway. Message-based delivery would be a MUST support (if notifications are supported). What I am a bit wary of, is that applications will start using it as the default mode, which creates an unnecessary burden on services for 90% of the use cases. IQ semantics do require more traffic, more processing and more memory usage. Given that the major selling point has mostly been 'reliability' and most uses of pubsub don't really need that, I would rather not see this getting into XEP-0060. > > - 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. Agreed. Presence subscriptions are a separate feature, solving other use cases. ralphm
