Hi Jonas,
Le lundi 7 janvier 2019, 18:08:25 CET Jonas Schäfer a écrit :
> 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.
I have thought about that too, but I took XEP-0313 as an example where the
common filters are using simple keywords ("start", "end", and "with" see
XEP-0313 § 4.1).
So I think this is alright to use keyword for the 2 most common cases, and URN
for extensions, in the same way as it is done in MAM.
> - Reversal via RSM seems wrong. You also can’t solve reversal via RSM when
> you
> use multiple levels of <order/> elements.
Lets say I have items 1, 2, 3, 4, 5, 6 and I want to get them by creation
order, 6 being the most recent, with a max of 2 per page, I would get with
normal request:
- 6, 5 (page 1)
- 4, 3 (page 2)
- 2, 1 (page 3)
But if I do backward using RSM's <before/> element, it would be
- 2, 1 (page 3)
- 4, 3 (page 2)
- 6, 5 (page 1)
(remember, RSM works by pages, so we just get the pages reversed).
In practice, the order if always DESC. But if the client want's to have ASC, it
just go backward using RSM, and reverse the result of each page (which is
trivial), so it would get 1, 2, 3, 4, 5, 6.
In both cases, requesting `<before>4</before>` gives `6, 5` (i.e. page 1) and
requesting `<after>3</after>` gives `2, 1` (i.e. page 3).
Multiple levels of ordering doesn't change anything to the deal, once
everything is ordered, we end up with a simple list of items.
> - 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.)
OK so we can stick with that significant order of elements.
> 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.
Yes RSM is not detailed enough, it's a really important thing to describe, I'll
work on it on next update. Do you think my example above is clear enough?
> 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.
Actually the problematic case is for item overwritting, i.e. if we order by
"date of modification" according to the protoXEP terms, and this default case
with XEP-0060 (there is nothing like "modification" or "update", but the result
is the same: if you overwrite an item, it jump on the top).
If you use the new order introduced by the protoXEP (date of creation), the
items won't move, they can only be deleted.
>
> (Note: the guarantees ("completeness" and duplicate-freeness) I am talking
> about are a "MAY" in RSM, §2.2, bullet points 2 and 3.)
yes I was about to mention it is a "MAY" too :). But I totally agree with your
points, I'll explain it clearly in next revision.
> 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.
We already have <published> and <updated> fields in Atom, but they are
specified by client, so this lead to majors issues:
- clock may not (and will not) be synchronised
- date can be faked
Also this would only be useful with blogging, while this feature is needed in
many others cases (like a pubsub tickets handler that I'm currently using).
Filtering on an arbitrary field is a possible future extension that could be
really useful. But let's do one thing at a time :).
++
Goffi
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
