Hi,
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.
Thanks.
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: [email protected]
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
--
With best regards,
Sergey Dobrov,
XMPP Developer and JRuDevels.org founder.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
