> We already have XEP-0184. Why define something new ... Sure. My point is that clients are easy to adapt for p2p ack, but when the server needs to participate, well that's beyond the scope of my current release.
>> but publishers shouldn't get acks from zillions of subscribers. > Agreed. But your application seems to have special requirements. It's not an IM app; the data published *has* to arrive, and data is often published when subscribers are offline. And hey, it was your blog that positioned XMPP against AMQP :-) On Wed, Feb 3, 2010 at 8:07 PM, Liam <pub...@networkimprov.net> 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 :) > > 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. > > The nature of "publish-subscribe" implies greater reliability than IM, to > my mind. One can implement a custom ack for peer-to-peer messaging easily > enough via <message/>, but publishers shouldn't get acks from zillions of > subscribers. > > Liam > > > > On Tue, Feb 2, 2010 at 12:25 PM, Liam <pub...@networkimprov.net> wrote: > >> >The core problem here is that presence is not necessarily reliable or >> >immediate. Does the notification ever show up anywhere >> >> No, it never shows up. I suspect the browser gets it but my handler for >> XmlHttpRequest is gone by then, so the data is tossed. >> >> >> >> On Thu, Jan 28, 2010 at 3:52 PM, Liam <pub...@networkimprov.net> wrote: >> >>> Any comments on the issue of reliable delivery to offline subscribers? >>> >>> I seem to have this issue with ejabberd. Having configured >>> pubsub#notification_type = normal (which queues items to offline >>> subscribers), if I disconnect a subscriber (by closing a browser tab running >>> strophe) and immediately publish an item, it doesn't always show up on >>> reconnect, presumably because it is "delivered" before ejabberd knows the >>> user is offline. If I wait a bit before publishing, the item does show up. >>> >>> >>> >>> On Thu, Jan 28, 2010 at 2:17 AM, Liam <pub...@networkimprov.net> wrote: >>> >>>> Perhaps I'm missing something here... >>>> >>>> That presence-based delivery is an optional service feature implies that >>>> items published are normally queued to node subscribers when they are >>>> offline, and later delivered when they sign on. However I can't find this >>>> explicitly stated in the spec. >>>> >>>> Also, the impact of persist_items on delivery to offline subscribers is >>>> not discussed. Is a non-persisting node inherently presence-based delivery? >>>> (Intuitively, I'd say not.) >>>> >>>> That on_sub_and_presence is an option for send_last_published_item could >>>> imply that items published when a subscriber is offline need not be queued >>>> for later delivery, which seems very strange. >>>> >>>> Also, I see no method for reliable delivery of items to offline >>>> subscribers... IQ notifications seem to address this only for online >>>> subscribers. This seems like a significant omission. >>>> >>>> I discovered this when I configured a node on ejabberd as follows, >>>> expecting it to queue items if the subscriber is offline, as for normal >>>> messages (which it doesn't): >>>> >>>> <field var='pubsub#notify_retract'><value>0</value></field> >>>> <field var='pubsub#persist_items'><value>0</value></field> >>>> <field var='pubsub#publish_model'><value>open</value></field> >>>> <field var='pubsub#access_model'><value>whitelist</value></field> >>>> <field >>>> var='pubsub#send_last_published_item'><value>never</value></field> >>>> >>>> Thanks, >>>> >>>> Liam >>>> >>>> >>> >> >
