Le samedi 12 janvier 2019, 20:50:25 CET Jonas Schäfer a écrit : > They do, here’s how: You have two metadata fields, let’s call them Time and > Author. You have the following data: > > Time Author Item ID > 10:00 Alice 1 > 11:00 Alice 2 > 12:00 Bob 3 > 13:00 Bob 4 > 14:00 Bob 5 > 14:00 Carol 6 > 15:00 Carol 7 > > Suppose I want the posts ordered Ascendingly by Author, and use the time as > tiebreaker, descendingly. The resulting set would be: > > 2 1 5 4 3 7 6
Oh you're absolutely right, with multi-levels we could change ordering (ASC then DESC like here) while I was supposing it's always DESC, my bad. I'll add a "direction" argument defaulting to DESC, thanks for the explanation. > […] > I don’t think that relates to what I was trying to say. RSM relies strongly > on > having a unique, immutable identifier for items (which is used in <before/> > and <after/>). On the *implementation* side (mind, I’m asking specifically > for > implementation guidance), I am not clear on what would be used here. Sure, > you > can use the Item ID, but there’s the problem that you cannot map that to an > SQL query with ORDER BY. You can use the classic "nth item in result set", > but > that loses the completeness and dub-free guarantees. OK I see. I have an implementation with SQL, and I'm doing an other SELECT with the item_id, I then get either the creation or modification date, and put it in a WHERE clause. But so far I was using one level of ordering, in case of multi-levels this is more complicated, I'll think about it, thanks for the pointer. > […] > The lack of clock synchronisation is a problem in any case, even when the > timestamps are generated on the server side, since XMPP is federated. I’d > even > argue that it is *worse* when the server is solely responsible, because there > is no way for a client to fix it. One node is on one server, so you have only one authority per node, the order will be consistent within that node (you can't achieve that by relying on X clients publishing X items). What I want to avoid, is what we have with email, where spammer put dates in future to be always on top. Note that this only influence the order, in XEP-0277 the creation and update dates (what appears to end-user) are set by the client. > I don’t see the faking of dates as an issue. At least for the blogging case. > Quite the contrary, I think it’s a good thing to have the flexibility (and in > a federated network, an adversary who wins by faking the dates can always > create their own server and spoof the dates there; so there’s no way for > clients to rely on those dates anyways). When you create a blog post, you usually also create the comments node on your own server, so you have control on both. When you visit a third party server, everything can be faked of course (including publisher jid and payload), but I suspect that the case when you want to visit a whole node maintained by a spammer is rare. So in nearly every common case, you can rely on the pubsub service dates for ordering. > On the other hand, I think that *not* letting the server do the date thing > and > instead selecting on the data already present in, for example, Atom, gives us > the advantage of being able to map existing Atom data into XMPP without loss > of usability and generality. I have plans for a future XEP allowing to order on arbitrary field, so client, knowing the context, could choose which method suits the best, but still I think it's important to be able to do it using pubsub service data. What to do if one or two items in a node are not following the right schema? Or if you use a XEP which doesn't set creation date? With pubsub service you are sure that the data is there and reliable (as long as you trust the node as said above). Note that ordering on arbitrary field is not that trivial, because Pubsub service doesn't know which fields are int, or dates, or something else. Also we would need a simplied XPATH like syntax, so a other XEP for that. If I can find some time today (I'm overwhelmed, so it's not sure at all), I'll try to update the protoXEP with all the insightful feebacks I've had sor far. Thank you all for those comments :) ++ Goffi _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
