On Sonntag, 6. Januar 2019 15:16:43 CET Jonas Schäfer wrote: > Title: Order-By > Abstract: > This specification allows to change order of items retrieval in a > Pubsub or MAM query
Couple notes:
- The strings for the "modification" and "creation" fields (as used in the
<order/> element) should be URNs, I think, to allow future extensions without
having to worry about conflicts.
- Reversal via RSM seems wrong. You also can’t solve reversal via RSM when you
use multiple levels of <order/> elements.
- In contrast to what Philipp thinks, I think that using multiple <order/>
elements (and having their relative order be significant) is fine; As goffi
mentions, pubsub itself is a valid precedent for that, and I think even a
XEP-0004 needs to be able to preserve the relative order of elements with
equal fully qualified name (i.e. namespace + local name) to render forms
nicely, so every implementation should support this. (As an aside, I generally
think anything which can be represented with a mapping-of-arrays is fair
game.)
I think this specification needs to be very clear how this stacks with RSM
(XEP-0059) and the underlying result set. In my mind, it stacks like this:
PubSub "Database" -> PubSub-level Filters -> order-by XEP -> RSM
I.e. it modifies the base Result Set in RSM terminology.
I think this XEP should also provide guidance how to integrate this properly
with RSM on the server side: It is not clear to me how a service could
sensibly pick <before/> and <after/> item IDs in a way which allows it to
reserve the guarantees of delivering a result set which does not lack items
which have existed for the entire time the query was being processed (I call
this property "completeness"), as well as a duplicate-free result set. If this
is not possible (and I believe that to be true), it should be spelt out
clearly in the XEP.
(Note: the guarantees ("completeness" and duplicate-freeness) I am talking
about are a "MAY" in RSM, §2.2, bullet points 2 and 3.)
(I think those guarantees are extremely useful, especially for a user
interface, and especially considering that the client does not have full
control over the page RSM size; if a user wants to see 200 items on a page,
but the server will only deliver 20 items in a single stanza, the client needs
to concatenate; while users may expect pagination to behave "interestingly", I
think the general expectation is that a single page in the view is in itself
consistent, which would not be the case if we have to drop those guarantees
and have to concatenate RSM pages.)
---
I am not completely sure whether it wouldn’t make more sense to specify an
extension which allows to sort by arbitrary (or specific) Atom fields and let
the Atom feed handle the management of modification/creation values. This also
allows to access Atom feeds which are only mapped/gateway’d into XMPP and
where the (authoritative) creation/modification times in the Atom feed then do
not match the times as perceived and thus used by the PubSub service.
kind regards,
Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
