On 01/28/2010 11:17 AM, Liam 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.
There's a combination of rules which creates a side-effect (see the last
paragraph below).
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.)
The persistence of an item is independent of the user state. If the
message is sent while the user is offline and that the user doesn't
receive it because of the node configuration, it can still retrieve it
later.
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.
If the node is configured to have persistent items, those items are
queued in there own Pubsub store, not in the user offline store.
So when the user subscribes to a node, and that node is configured with
'send_last_published_item' = 'on_sub_presence', the user will receive
the last item from the Pubsub store, not from his offline one.
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>
In your case, offline messages are not stored (and hence not delivered)
because, by default, ejabberd/mod_pubsub nodes are configured with
'pubsub#notification_type' = 'headline'. And it is a usage that
'headline' type messages are not queued in the XMPP core server offline
store.
Setting 'pubsub#notification_type' = 'headline' as default is a way to
avoid having the user offline store quickly flooded.
There can be the following combinations (amongst others) :
* #presence_based_delivery = '0' and #notification_type = 'normal' :
The Pubsub server sends all messages, messages are queued in the XMPP
core server offline store, and the user receives all messages next time
he gets online ;
* #presence_based_delivery = '0' and #notification_type = 'headline' :
The Pubsub server sends all messages, the XMPP core server doesn't
store those messages, and the user will only receive messages sent while
he is online ;
* #presence_based_delivery = '1' and #notification_type = 'normal' :
The Pubsub server sends messages only when the user is online, so the
XMPP core server storage is not involved ;
* #presence_based_delivery = '1' and #notification_type = 'headline' :
Same as previous case.
--
kael
