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. 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. This is most particularly acute in PEP cases, where the single item id is traditionally fixed. * 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/>, nor even an extension to XEP-0060's <pubsub/> - Failure cases are given as an <iq/> of type "result". * 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. 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. As a bonus, you could also define lots of fun things like having both the current and previous version on events, and a resynchronizing get-items replacement (MAM, anyone?). Dave. On 24 August 2017 at 13:10, Jonas Wielicki <[email protected]> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Atomically Compare-And-Publish PubSub Items > Abstract: > This specification provides a mechanism to atomically Compare-And- > Publish items to a PubSub node. > > URL: https://xmpp.org/extensions/inbox/cap.html > > The Council will decide in the next two weeks whether to accept this > proposal as an official XEP. > _______________________________________________ > 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] _______________________________________________
