On 25 August 2017 at 10:17, Florian Schmaus <[email protected]> wrote: > 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. >
Yes, I wasn't clear. Publish to a node with a client-supplied item id. > 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). > Actually, even if the publish in (3) is conditional, I think the same thing applies - because item ids can be (and often are) reused, merely knowing the last id published does not indicate that the client knows what the item payload was. >> 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. Dave. _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
