> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >>> >> >
