Date: Wed, 3 Feb 2010 20:23:08 -0800
From: [email protected]
To: [email protected]
Subject: Re: [PubSub] What's NON-presence_based_delivery mean?
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
These two are reasonable to accomplish reliable delivery.
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
This is not really a pubsub model. There is no direct link between publisher
and subscriber. The publishers only real concern is that the information was
actually published.
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
_________________________________________________________________
Check your Hotmail from your phone.
http://go.microsoft.com/?linkid=9708121
