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

Florian Schmaus flo at geekplace.eu
Fri Aug 25 09:17:02 UTC 2017


On 25.08.2017 10:08, Dave Cridland wrote:
> I think the premise looks reasonable - that is, a publish conditional
> on the last item to be published being known.
> 
> However, this protocol as defined has several flaws:
> 
> * It doesn't do what it claims.
> * It's an awkward syntax.
> * It fails to define what "latest id" means.

Thanks for your feedback Dave.

> Going through each:
> 
> * It doesn't do what it claims
> 
> Given the following sequence, the "Compare And Publish" will
> unexpectedly work when it should fail:
> 
> 1) Publish to Item 1
> 2) Event for Item 1
> 3) Publish to Item 1
> 4) Publish Item 2 conditional on Item 1 being "latest"
> 5) Event for Item 1
> 6) Event for Item 2
> 
> In other words, the race this protocol attempts to resolve still
> exists.

I'm confused that you talk about publishing to a *item*. My assumption
was that you publish to nodes, where every node has a ordered list of items.

Is 3) a publish without compare-and-publish? If so, then yes the race
still would exists. As soon as one participant does not use
compare-and-publish, the race can't be solved (without enforcing
compare-and-publish server-side).

> 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.

All in all, the point you are trying to make here is not clear to me.

> * It's an awkward syntax
> 
> A matter of taste, to be certain, but nevertheless there are some
> frankly weird choices here:
> 
> - It's a publish, but it's not a <publish/>, 

I think that's similar to what Kim suggested: Using a publish-options
field instead of a new element (<compare-and-publish/>).  I'll will
comment on that as reply to Kim's mail later.

> nor even an extension to  XEP-0060's <pubsub/>

Would it be a good idea to define a new child element for <pubsub
xmlns='http://jabber.org/protocol/pubsub'/> in an add-on XEP? I don't
think so, that's why it's not an xep60 <pubsub/>.

> - Failure cases are given as an <iq/> of type "result".

Hmm, it's been a while ago when I wrote that. I'm pretty sure I had some
reasons but can't remember. Happy to change that to 'error'.


> * It fails to define what "latest id" means.
> 
> Is this the latest id to have had an item published? I'm reasonably
> sure it is, based on the surrounding prose, but it could also be the
> latest id to be newly minted, in which case I have the entire premise
> incorrect.

Good point, I think. When is an item minted but not published? Are
PubSub services allowed to make a new item visible prior sending the
event for the new item? I guess there is always a inconsistent state
between the event notification arriving at an entity, and that entity
querying the node's item(s).

> 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)?

- 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/4eb4e9c7/attachment-0001.sig>


More information about the Standards mailing list