Hi, On Fri, Feb 19, 2010 at 9:06 AM, Joe Hildebrand <[email protected]> wrote: > On 2/19/10 12:47 AM, "Evgeniy Khramtsov" <[email protected]> wrote: >> Pedro Melo wrote: >>>> There are a myriad of ways the original IQ or the ack could get lost. My >>>> point is that the response does not serve any value to the sender, since I >>>> don't believe there is anything useful to be done when the sender does not >>>> receive the ack. Resending is almost always going to be wrong. >>>> >>> >>> Why? I think the exact opposite is true. We have item ID's so we can >>> ignore duplicates. > > So you retry, and don't get a response. What now? Retry?
Yes. Probably with a exponential back-off and with a retry limit. Also, a good pubsub implementation would skip sending further notifications to this JID until he does get a reply. It really depends on the contract (and I use this in a liberal way) the client has with the pubsub service in question. If I subscribe a service via pubsub from a provider for a topic that is critical to me, I expect the pubsub implementation to try its hardest to deliver my notifications. The provider might require extra fees for this type of service for example (and we can finally see <payment-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> in the real world), thats ok. What I'm trying to say is that I don't want to limit potential uses of this, <iq>-based delivery. So the policy of retries should be suggested but leave space for per-deployment adjustments. Getting your real-time-fix of RSS will probably need different policies than a stock ticker. > Let me ask a different question. What are you going to do if you get a > response? It the pubsub gets a <iq type="result">? Then the delivery was successful. If we get a error, then it depends if it is a recoverable or temporary error condition, or permanent. >> I guess because if a sender doesn't receive the response, this doesn't >> mean a receiver doesn't receive the request. > > Yes, although Pedro has a point that the id's allow you to discard > duplicates. Exactly. Bye, -- Pedro Melo http://www.simplicidade.org/ xmpp:[email protected] mailto:[email protected]
