Hello, I've read the council logs, I'll try to defend the protoXEP here (in addition to what has already been said in this thread). > it's a very specific use case, and it defines two hard-coded properties to > order by. A clean approach would allow ordering by any field of the items, > using some XSLT magic or something. ([16:04:52] <Ge0rG>)
It's not a niche case at all, it's a major feature for blogging, and many other experimental features I'm working on and hope to standartize in the not too distant future (like tickets handler, forums or events). It seems that at least Movim would be interested too (cf. message from edhelas at https://mail.jabber.org/pipermail/standards/2018-August/035316.html). In my opinion, it is an important missing feature at the moment. About the ordering on arbitrary field, this has been debated with Jonas already (cf. https://mail.jabber.org/pipermail/standards/2019-January/035642.html): it is a future plan but will complicate a lot (a XEP for XPATH like syntax, the issue with data type, and the fields which can be missing in items, to quote the most important issues). > this needs to be renamed "PubSub MAM retrieval ordered by creation or > modification" ([16:07:42] <Ge0rG>) I'll make an update to restrict to Pubsub, this doesn't have really much use/sense for MAM with instant messaging. Beside that, the XEP already states that it is extensible, it's not a pubsub only thing. I think for instance that it would be really useful to get list of MUC rooms ordered by number of participants, or order of creation. > I did notice this applies to MAM, too, but doesn't disucss it, and presumably > has quite an impact on RSM, but doesn't mention that. ([16:07:49] <dwd>) As said above, I'll restrict MAM to pubsub only. RSM is not impacted (there is the ID which could be something else than item_id, as noticed by Jonas, but this is already a RSM thing, nothing new). I'll mention the RSM after/before ID thing in next update. > I wouldn't be unhappy to see this have more work on it before it's published > ([16:09:06] <Kev>) Sure this was a first draft, I'll try to find time to update it today or tomorrow. > my rationale is that it's only adressing a very specific use case, and > requires changes to multiple other XEPs, like PubSub (for storing metadata) > […] it implies changes to their implementation. ([16:09:46] and [16:10:36] > <Ge0rG>) No other XEP is modified. About implementation changes, well most of XEPs imply implementation changes. For Pubsub services based on SQL or NoSQL databases, it should not be too hard to implement as ordering is most of time a part of API. For Pubsub services based on flat files (I think it's the case for Prosody), well the feature is not mandatory, and the doc can say that this feature needs an other backend. For the metadata, there is not much to do: - ordering by modification time as defined in the XEP is actually the current default ordering of Pubsub, so there is nothing to do - ordering by creation date needs to keep the date of first item with a specific ID. In practice, you can do that by copying the date (or uid or whatever you're using) on the new item when you have an ID conflict, before destroying the old item, nothing fancy. That's it, I hope I have convinced you. Anyway this is experimental, time will show where it goes. ++ Goffi _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
