[Standards] Proposed XMPP Extension: Atomically Compare-And-Publish PubSub Items

Florian Schmaus flo at geekplace.eu
Fri Aug 25 14:22:56 UTC 2017


On 25.08.2017 13:39, Dave Cridland wrote:
> On 25 August 2017 at 10:17, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 25.08.2017 10:08, Dave Cridland wrote:
>>> This is most particularly acute in PEP cases, where the single
>>> item id is traditionally fixed.
>>
>> Isn't the item ID always fixed, stable and unique (see xep60 § 12.8)?
>> I've a sense that there is some confusion about item and node wrt. to
>> PubSub. Maybe on my side.
>>
> 
> The last id is fixed for a given publish, is stable throughout the
> item's lifetime, and is unique at a given instant for a node.
> 
> It is not, however, unique for all time, since they can be reused.
> 
>>> As a strawman counter-proposal, what about:
>>>
>>> * Defining a mechanism similar to roster versioning for pubsub nodes.
>>> * From there, defining a conditional publish based on the node version.
>>
>> What's the difference between the PubSub node version you propose and
>> defining the PubSub node "version" as the item ID of the newest item of
>> a PubSub node (which my XEP does)?
> 
> I think my strawman will handle a retraction, which - again I think -
> your proposal would not.
Ugh, my assumption was that the same node ID will always refer to the
same content of an <item/>. But after re-reading xep60 § 12.8 I found
the following:

"""
If a publisher publishes an item and the ItemID matches that of an
existing item, the pubsub service MUST overwrite the existing item and
generate a new event notification.
"""

Well that complicates a potential compare-and-publish (CAP) protocol
somewhat. Then indeed we need to define a new unique handle which refers
to the latest node item state and changes if the item changes in any way
(regardless whether the item id stays equal or not).

It would be much easier if xep60 would guarantee the node's content
could not change without a node ID change. I condemn that design
decision a bit.

But anyway, it appears we have to live with it. I'll work on an updated
version of CAP in the following days/weeks.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 642 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170825/4abfa2f2/attachment.sig>


More information about the Standards mailing list