[Standards] XEP-0163: Personal Eventing Protocol - Clarification about the multi-items per node support

Sergey Dobrov binary at jrudevels.org
Mon Jan 9 08:20:08 UTC 2017


It seems to me that in case you have persist_items=1, it effectively 
means that the node can not store more than 1 item, i.e. the second item 
will replace the first one. In case it's zero node won't store any items 
at all and will only broadcast the events, you won't be able to retrieve 
the items afterwards:

 > Implementations of pubsub that choose to persist items MAY allow 
entities to request existing items from a node (e.g., an entity may wish 
to do this after successfully subscribing in order to receive all the 
items in the publishing history for the node).

 > Even if the service or node does not support persistent items, it MAY 
return the last published item.

So there is nothing in common with server reboot, you either can 
retrieve items (up to the number of configured persist_items) from a 
node or you can't.


On 09/01/2017 09:48, Jaussoin Timothée wrote:
> Hi,
> I do think that there is a difference between the "persist_items" and
> the "multi_items" field that I'm proposing. The items persistence field
> actually just say "Whether to persist items to storage", in other words,
> "items are resilient to server reboot".
> To me that doesn't say if the server support several of them on
> Pubsub/PEP nodes.
> Regards,
> Timothée
> On 05/01/2017 18:38, Sergey Dobrov wrote:
>> Hi Tim, nice to read you.
>> It seems to me that there's no problem in it, actually. Since you've
>> configured a node to contain more than one "persist_items" and the
>> configuration succeed, you do know the node is fine to store more than
>> one item?
>> Thanks.
>> On 05/01/2017 00:52, Jaussoin Timothée wrote:
>>> Hi,
>>> After having a look at XEP-0163: Personal Eventing Protocol and
>>> XEP-0060: Publish-Subscribe I'd like to have a clarification regarding
>>> the multi-items per node support.
>>> PEP is meant to be a "a simplified subset of pubsub" and was defined to
>>> work with nodes created on the user JID. Also this XEP is mostly used
>>> for nodes that only contains one <item> (like in XEP-0118: User Tune,
>>> XEP-0107: User Mood, XEP-0108: User Activity or XEP-0080: User
>>> Location).
>>> However some later XEPs allows clients to publish several items per PEP
>>> nodes like XEP-0277: Microblogging over XMPP or XEP-0330: Pubsub
>>> Subscription (we are also planning to update the Bookmarks XEP to work
>>> this way, one bookmark per item, mostly to prevent race-condition
>>> issues).
>>> My main concern here is that a XMPP client currently don't have a way to
>>> know if the server supports several items per node for PEP (like for the
>>> current Prosody server).
>>> Having this lack of information could lead to issues with XEPs that rely
>>> on this multi-items support in client implementations (that it's
>>> actually the case with clients like Movim).
>>> I don't see any feature listed here
>>> http://www.xmpp.org/extensions/xep-0060.html#features that could help
>>> clients to get this information (maybe
>>> http://jabber.org/protocol/pubsub#item-ids ?).
>>> If its not a misunderstanding on my side, I'd like to have your point of
>>> view on this problem and start to discuss about a solution.
>>> Regards,
>>> Timothée Jaussoin aka edhelas
>>> _______________________________________________
>>> Standards mailing list
>>> Info: https://mail.jabber.org/mailman/listinfo/standards
>>> Unsubscribe: Standards-unsubscribe at xmpp.org
>>> _______________________________________________
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.

More information about the Standards mailing list