On 2/4/10 2:34 AM, Kirk Bateman wrote: > Inline comment below > > On 4 Feb 2010, at 04:22, Peter Saint-Andre <[email protected]> wrote: > >> On 2/3/10 9:07 PM, Liam wrote: >>>> Understood. I'm going to chat about this with Jack Moffitt at the XMPP >>>> Summit next week to see if he has any insights. I'm not a web guru. :) >>> >>> Tell him I said hi (I've been working on the strophe pubsub plugin a lot >>> recently :) >> >> Will do. :) >> >>> I improved my browser-tab-close issue by ensuring that strophe issues a >>> disconnect on tab-close. However there is no way to know that a stanza >>> which tcp transfers ok has been processed by the client without an >>> explicit ack mechanism. Closing a tab, etc. won't close the socket right >>> away, or even stop reading it. >> >> Right. Did you read XEP-0184? >> >>> The nature of "publish-subscribe" implies greater reliability than IM, >>> to my mind. >> >> Not to mine. I care more about a personal IM conversation than some >> random syndicated data. :) But YMMV. >> > Peter, how about if xmpp was being used for financial transactions. I'd > probably use pubsub for that as a queue type thing ( as mq systems are > often used currently ). Surely that needs a bit more in the way of > guaranteed delivery ? Just a thought.
Those weren't the original use cases for XMPP. We've slowly built more reliability into XMPP, but *guaranteed* delivery (like "security") is not something you just sprinkle on top. :) Even, say, XEP-0184 for end-to-end acks doesn't *guarantee* that a message was properly handled at the receiving end or shown to a human user (only that the receiving application got the stanza). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
