Liam,
Sounds like a reason to have the client side check for new posts on
connect. This was something I thought about quite a bit with
Buddycloud ideas.
Essentially, you can have a situation where you need to have a pull to
check for missed items while offline, I think I mentioned it on the
list when we were talking about version or timestamps for published
items.
Currently I can't think of another solution, apart from something like
using iq to publish instead of messages so the delivery is
guaranteed ? (doesn't even sound good to me, although I think wave
possibly does something along those lines)
Regards
Kirk
On 28 Jan 2010, at 23:52, 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
