Hm revert that, i actually dont know what ejabberds PEP impl does in this case.
Regards Philipp 2018-08-08 17:57 GMT+02:00 Philipp Hörist <[email protected]>: > And this brings us to the next critical question which affects all PEP > reliant XEPs > > https://xmpp.org/extensions/attic/xep-0060-1.11.html# > subscriber-subscribe-last > > What is the last published item? The last modified item or the last > published under a new ID > > Seems all PEP implementation that i know choose the last modified item > (Also ejabberd). > But if the last published item is also the last modified then it follows > that the most recent should also the last modified, otherwise i would find > this not very consistent > > Regards > Philipp > > 2018-08-08 17:48 GMT+02:00 Timothée Jaussoin <[email protected]>: > >> Le mercredi 08 août 2018 à 16:32 +0100, Matthew Wild a écrit : >> > On 8 August 2018 at 16:17, Peter Saint-Andre <[email protected]> >> wrote: >> > > On 8/8/18 3:17 AM, Philipp Hörist wrote: >> > > > I always thought the most recent refers to the publish date/time of >> the >> > > > item, hence if i override a item it also changes the updated >> time/date >> > > > and it becomes the most recent >> > > >> > > That seems reasonable. So it's really "last modified item". I'm >> curious >> > > what Ralph thinks. >> > >> > Me too. >> > >> > I personally have always shared Philipp's interpretation. A publish of >> > an item is a publish, whether another item already existed with that >> > id or not. >> >> So it's a https://xkcd.com/1172/ case for me. >> Having a "social network" implementation using Pubsub this behavior is >> going against the current flow that I'm using in Movim. >> If you edit an article on a social network or a blog it shouldn't move >> back to the top of your feed. It is also, afaik, how ejabberd is >> handling it. >> >> In both cases, does the disco#items (https://xmpp.org/extensions/x >> ep-0060.html#entity-discoveritems) and query items ( >> https://xmpp.org/extensions/xep-0060.html#subscriber-retrieve-returnsome) >> IDs order should be consistent then? If it's the case then >> using RSM on disco#items should be enough to "refresh" what the client >> missed on a node (give me all the items published after the ID >> of the last updated item that I have in my cache) without actually having >> to compare the payloads. >> >> I'm also wondering if this affects https://xmpp.org/extensions/xe >> p-0395.html. >> >> Regards, >> >> Timothée >> >> > >> > I'd say this interpretation also makes the most sense if you consider >> > the perspective of someone subscribed to the node. Requesting the >> > items will return the same items in the same order that you would have >> > received them while subscribed, with the obvious exception of items >> > that have been replaced. >> > >> > Regards, >> > Matthew >> > _______________________________________________ >> > 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] >> _______________________________________________ >> > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
