Pubsub - problems publishing and item with a specific ID

Here I am again, riding my pubsub hobbyhorse, heh.

Very slightly different question this time though.

Let’'s say I wanted to publish my age in pubsub like:

I was a bit puzzled to find that doing this more than once with different ages (at least for a multi-item node) does not work as I would have expected.

Unless I first retract the item, republishing an item with the same id results in multiple items with random identifiers. Now, I realize the item id actually created is returned in the result, but it doesn’'t seem logical to me to allow a user to specify an item ID if there is a chance that it will be ignored! If I specify the item ID, then I probably have a purpose for it.

I’‘d have thought it was more logical to either reject publication of items with duplicate IDs or to simply replace the item. I couldn’‘t find anything in XEP-0060 specifying what should happen in this case, so I’'m not sure what changing this behaviour would impact.

I guess it’'s not a big issue as long as I make sure to ‘‘retract’’ before ‘‘publish’’, mainly just commenting on what seemed to be a logical flaw. And also that rejecting publication of a duplicate item ‘‘id’’ for a node is logically inline with rejecting creation of a node with a duplicate node ID.

Chris Denham

Message was edited by: cmd4

Hey Chris,

If I recall correctly when we implemented pubsub it was not possible to update published items. I see that the latest version of the spec allows that to happen:

Note: If a publisher publishes an item with an Item ID and the ItemID matches that of an existing item, the pubsub service MUST NOT fail the publication but instead MUST overwrite the existing item and generate a new event notification (i.e., re-publication is equivalent to modification).

As you noticed the way to implement an update with the current Wildfire is to delete the old item and create a new one. There is a jira issue to update our pubsub implementation to the latest version so this issue will be fixed in a future version.


– Gato

Thanks again Gato.

That’'s good news!