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. > One can implement a custom ack for peer-to-peer messaging > easily enough via <message/>, We already have XEP-0184. Why define something new that does the same thing? > but publishers shouldn't get acks from > zillions of subscribers. Agreed. But your application seems to have special requirements. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
