[Standards] XEP-0060: Item ordering

Philipp Hörist philipp at hoerist.com
Wed Aug 8 16:03:42 UTC 2018


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 <philipp at hoerist.com>:

> 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 <edhelas at movim.eu>:
>
>> Le mercredi 08 août 2018 à 16:32 +0100, Matthew Wild a écrit :
>> > On 8 August 2018 at 16:17, Peter Saint-Andre <stpeter at mozilla.com>
>> 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: Standards-unsubscribe at xmpp.org
>> > _______________________________________________
>>
>> _______________________________________________
>> Standards mailing list
>> Info: https://mail.jabber.org/mailman/listinfo/standards
>> Unsubscribe: Standards-unsubscribe at xmpp.org
>> _______________________________________________
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180808/f229e413/attachment.html>


More information about the Standards mailing list