> That said, we could define fairly simple message formats for both the > bounce notifications and delivery-complete notifications.
Sounds promising; and would xep 0184 be the ack mechanism to the pubsub service? (I think 0184 needs a param indicating the retry count, e.g. <request attempt="N"/>.) 0184 says retry method is up to sender. A pubsub node doing bounce notification will need retry config. On Wed, Feb 3, 2010 at 8:23 PM, Liam <[email protected]> wrote: > Thinking more about this, I want... > > subscriber to ack to service the pubsub event message > service to retry to subscriber by a configurable method if no ack > service to report fail to publisher when retries spent for a specific > subscriber > service to report done to publisher when all subscribers either acked or > failed > > Thoughts? > > > > On Wed, Feb 3, 2010 at 8:07 PM, Liam <[email protected]> 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 <[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 >>>>> >>>>> >>>> >>> >> >
