On 3/22/10 10:59 AM, Ralph Meijer wrote: > 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.
AMP would be very nice, but it's not implemented in servers today, whereas IQ support is universal. > 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. I think those who have advocated IQ-based notifications would argue that waiting until AMP has been implemented and deployed more widely would cause unnecessary (perhaps interminable) delays. Given that XEP-0079 was advanced to Draft in October 2004 and still has not been implemented in more than one or two servers, I would tend to agree. >>> 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. That seems to be a tradeoff that some pubsub implementors are willing to risk, at least experimentally in order to gain more experience with increased reliability. >>> - 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). Indeed. > 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. I agree that relatively few pubsub applications need IQ-based notifications. Perhaps we need two things: 1. A clearer description of the use cases that truly need IQ-based notifications. 2. An applicability statement that strongly discourages IQ-based notifications unless absolutely necessary. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
