[Standards] XEP-0060: order of items

Jonas Schäfer jonas at wielicki.name
Thu Nov 11 07:15:09 UTC 2021


Hi Goffi,

On Mittwoch, 10. November 2021 16:40:54 CET Goffi wrote:
> Le mercredi 10 novembre 2021, 15:26:55 CET Holger Weiß a écrit :
> > * Goffi <goffi at goffi.org> [2021-11-10 10:39]:
> > > It should be spelled out clearly how items are returned (even if
> > > unordered, bug again I don't think that it's a good idea to have
> > > unordered items by default on pubsub).
> > 
> > Updating the spec won't update implementations, so unless you also add a
> > new '60 feature that servers can announce, the client still can't make
> > assumptions regarding the ordering, no?
> 
> I saw that as something only missing from text, and spelling it out clearly
> would allow to open bug reports on pubsub implementations following a
> different order (from my interpretation, the order was clear from examples,
> but I know that examples are not specifications).

I concur with Holger on this one. The ticket you linked shows that at least 
one implementation has interpreted the text differently, so this is not a 
"clarification" where everyone agrees, but a thing where not everyone is in 
agreement.

That would make the proposed change to XEP-0060 practically (and not just 
formally) a breaking change. (And as a reminder, XEP-0060 is Stable.)

As Holger points out, you cannot magically make existing implementations 
adhere to that anyway. So the choice is between updating '413 to do the 
absolutely minimal thing and offer a way to indicate support only for creation.

One middle ground would be to define a disco#info flag to indicate that pubsub 
results on a service are always ordered by publication ascendingly (or 
somesuch) to advertise the behaviour you want -- but I think a clean solution 
based on '413 would be better.

> I can update XEP-0413 to make implementation of "creation" optional (with
> suitable disco#info) thus XEP-0060 would be officially unordered. I just
> hope that implemenation will follow and we won't keep the status quo for
> years.

Whether the change is in '413 or in '60 doesn't really matter -- 
implementations need to be fixed anyway. See it as a way to push for '413 
support, I guess.

As a tangential, I'd suggest to drop the MAM part from '413 to narrow the 
scope unless you specifically have a use-case for that (as MAM now properly 
supports selecting a range by before-id/after-id, so you can page backwards 
with RSM as needed).

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20211111/22fc9bb5/attachment.sig>


More information about the Standards mailing list