XSF Discussion - 2023-03-18

So what should "publishing a pubsub item with an existing ID" do? keep the original published position? make it a new published item?

pep.: Remove the old item but bring to front the new item in order, sounds like

Should a retract be issued?

That'd be weird I guess..

edhelas, goffi ^

I guess as a client it "doesn't really matter", you'll want to use order-by when you depend on the order of items

I don't think you need a retract since you get the new item

But terminology matters for servers here, if we specify "discard-oldest" we need to know what oldest means so all implementations delete the same

What defines the age though? Creation date? Last update date?

To quote MattJ, "there is no date" :P

It'd be creation/publication time(date)

Guus, that's what we're trying to ""clarify""

Update "time"

"Update" isn't a specified operation it seems atm

To quote Buzz Lightyear: dates, dates everywhere

Only publication and retraction

Well, it is

That's what we're talking about

Publish with same ID overwrites

singpolyma, well the spec doesn't say, does it

And makes the item "new"

That's what we're trying to clarify

Sure, the discussion started because we need to add words that say that

Yes

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

> 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). This also. ✏

So it's possible to modify an item?

But that still doesn't say much about the order IMO

pep.: publishing a item with existing ID is publishing a new item (i.e. not overwriting), so there is no position to keep. The Order-By XEP (XEP-0413) that I've authored introduces the overwriting notion, but with XEP-0060 alone, it's a new item, and the old one disappear (but I would not expect a retract).

and yes order-by is mentioned after, sorry I'm answering while reading.

with XEP-0060 alone, there is no "update"

again, it's introduced by XEP-0413

So.. there seems to be consensus already around the existing item being removed from the node and the new one to be published? In the two quotes above from 0060, it says "overwrite", which is confusing

yeah, no there is no overwrite, I remember talking about that with ralphm at some point.

So.. in 0060 there is no way to "update" an item. That settles it

yes

it's even said in XEP-0413: "In XEP-0060, there is no such thing as "updated item". This XEP changes the business logic as follow:" (in Glossary)

Yep thanks

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

hmm

"Depending on node configuration"? Which one

BTW, slide topic change, but is the EDITOR situation fixed now?

EDITOR=vim. Fixed

goffi: we had new editors step up before the resignation of the old one, so from that perspective there wasn't anything to fix

MattJ, pubsub#notify_delete? :/

So the default behaviour would be delete-oldest and not disacrd-oldest?

Obviously there has been a period for the new editors to get up to speed, but we're getting there

Basically the "retract" I propose?

pep.: I think it means retraction notifications

I don't think there is anything else, but I'm prepared to be surprised by XEP-0060 as usual

Well there's notify_delete and notify_retract

Maybe delete applies to a node and not an item

Makes sense, but do the notifications look any different to the recipient? 🤔

MattJ: OK thanks. I was wondering because I haven't seem much activities in XEPs lastly.

https://xmpp.org/extensions/xep-0060.html#publisher-delete Looks like it's the case yeah, delete -> node, retract -> items. Even though the use of "Delete" in the spec is confusing

goffi: I think the email announcements of XEP changes are WIP, but stuff has been happening regardless

MattJ: OK great. And thanks to the people involved.

Mostly Kev to thank right now 🙂

so thanks Kev :)

I'll modify this part of the spec as well then, the RECOMMENDED sentence

pep.: I have followed from a distance, but a delete by default would be niced from a caching point of view.

nicer*

what do you mean "a delete"?

I mean receiving a notification when items are retracted due to full node, instead of simply discarding them. Otherwise you don't know that you can remove the item from cache.

Well it seems the spec already recommends a retraction

If the server's order is well-defined, and max_items is set and known, you should be able to work that out locally without the overhead of an additional notification on every publish

Yeah but the server should be able to do something about it anyway, when a publish happens in this case

if max_items is know it should be fine indeed, but is it given in node metadata by every pubsub service?

I'm okay with that being configurable, and okay with it being default/recommended, but I would like it to be possible to silently discard old items if configured that way

goffi: it should be

It's one of the standard config fields

MattJ, if configured this way then sure. But that certainly shouldn't be the default as RECOMMENDED/SHOULD in the spec

I'm OK with it being configurable too, defintely, it should be configurable

+1

I'm pretty sure Prosody has no capability to notify in this case, but I can certainly add it

I don't think Libervia Pubsub does it either to be honest. Something to add in my (very very long) TODO list

That, and a way to redirect Prosody internal pubsub API to the component.