On 2023/03/17, Matthew Wild wrote:
> I actually think the current behaviour of Prosody (and I think
> ejabberd? others?) is definitely desirable in some cases, and I
> propose making it an explicit option ('discard-oldest'?) - in this
> mode the node is effectively a cache of the most recent items.So a chat on xsf@ brought some more light to this. It appears that the “retract” option that I am adding is already a SHOULD (RECOMMENDED). So in addition to “retract” that I'll probably rename “retract-oldest” to be slightly more explicit, I don't mind adding a “discard-oldest” option. Retracting being the default. § 7.1.2 https://xmpp.org/extensions/xep-0060.html#publisher-publish-success > Note: If the service or node is configured so that there is a maximum > number of items cached at the node and the maximum is reached when an > item is published, the service MUST delete one of the existing items. > It is RECOMMENDED for the service to follow the "first in, first out" > rule and delete the oldest item. Depending on node configuration, > deletion of an existing item MAY result in sending of a delete > notification to the subscribers. This “delete notification” configuration the text talks about is probably “pubsub#notify_retract”. Confusing terminology. “Delete“ seems to be used in the case of nodes, “retract” in the case of items. This paragraph also uses the word “oldest” which isn't exactly clear in this document, but from what I gather, there are only two operations possible for an item, publishing and retracting. There is no specified way to update an item, but only some text that suggests it. See below. For “oldest”, adding informational text that clarifies it would be good, and can / should happen in this PR / revision. A definition could be ”ordered by publication [time]”, except if we mix in updates, which aren't really defined but the fact of overwriting an item is mentioned in multiple places: § 7.1.2 https://xmpp.org/extensions/xep-0060.html#publisher-publish-success > Note: If the publisher previously published an item with the same > ItemID, successfully processing the request means that the service > MUST overwrite the old item with the new item and then proceed as > follows. § 7.1.3 https://xmpp.org/extensions/xep-0060.html#publisher-publish-error > 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). § 12.8 https://xmpp.org/extensions/xep-0060.html#impl-uniqueness > 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. The term “overwrite” isn't defined anywhere. Should: 1. The original item be removed and the new item published in its stead same publication time as the original one. Or the original item be updated with contents of the new one. Technically the same. 2. The original item be removed and the new one be published as a new item. (Any more?) I think the text can be read to fit both. Discussion on the xsf@ channel seems to suggest 2. is preferred: https://logs.xmpp.org/xsf/2023-03-17?p=h https://logs.xmpp.org/xsf/2023-03-18?p=h We certainly do need to settle on one of these, as it allows us to agree on the order in which to retract/discard items for the original issue here.
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
