On Fri, Sep 18, 2009 at 7:48 PM, Kevin Smith <[email protected]> wrote: > On Thu, Sep 17, 2009 at 3:20 PM, Fabio Forno <[email protected]> wrote: >> See the other thread (I was late in the reply sorry): I plan to make >> it available only with presence subscriptions. > > Is there a rough agreement that the 'real' solution here, in the > perfect world of having all XEPs available to us, would be 198 for > reliable delivery, and message expiration in the events? Not arguing > for or against hashing out something that would work Right Now, but > it'd be good to be clear about what the ideal would be (and how far > away from it we are).
Well, while I'm 100% sure XEP-198 is the solution for the last hop (especially for session recovery which would save tens of KBs each reconnection), I'm not sure that for this specific case it works as fine as an <iq/>. From my point of view the reason is simple: we must use three XEPs (99, 184, 198) to replicate the exact semantics of an <iq/> with a <message/> stanza, i.e. we must do a difficult thing for reinventing an easy one which already exists. As far I know the only objection against an <iq/> option for delivery is that it works only with presence subscriptions, which is not a big deal imho (I can't imagine a scenario where we want reliable delivery to a given client and no presence subscription) bye -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: [email protected]
