[Xesam] Sorting API to be more flexible

[Evgeny Egorochkin]

В сообщении от Wednesday 25 June 2008 10:36:41 Mikkel Kamstrup Erlandsen 
написал(а):
> 2008/6/24 Evgeny Egorochkin <phreedom.stdin at gmail.com>:
> > В сообщении от Tuesday 24 June 2008 16:05:54 Mikkel Kamstrup Erlandsen
> >
> > написал(а):
> >> 2008/6/24 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> >> > 2008/6/13 Mikkel Kamstrup Erlandsen <mikkel.kamstrup at gmail.com>:
> >> >> 2008/6/13 Jos van den Oever <jvdoever at gmail.com>:
> >> >>> 2008/6/13 Urho Konttori <urho.konttori at nokia.com>:
> >> >>> > We have been evaluating the Xesam for multiple uses at Nokia and
> >> >>> > one of them is media player use. In many cases, where all the
> >> >>> > songs need to be listed, they need to be listed with three sorting
> >> >>> > criteria: Artist, Album, Track#. Xesam provides only two sorting
> >> >>> > criteria. Now, you might argue that the application should do the
> >> >>> > tertiary sorting, but then if we say that, then why two sorting
> >> >>> > criteria, or one?
> >> >>> >
> >> >>> > I'm quite sure this is not the only use case where tertiary
> >> >>> > sorting (or even more) would be beneficial.
> >> >>> >
> >> >>> > Also, the API looks a bit glued when you have primary and
> >> >>> > secondary sorting as the session properties. Why not instead
> >> >>> > change it to an array of sort criteria? So, as to call it just
> >> >>> > sort.fields?
> >> >>> >
> >> >>> > It would be very good if this sort of change could still be done
> >> >>> > to the xesam 1.0 spec, either next to the current primary and
> >> >>> > secondary sorting, or better yet, as the only way to set the sort
> >> >>> > order. It would be much cleaner way to do it.
> >> >>> >
> >> >>> > Anyway, I'm looking forward to comments on the subject.
> >> >>>
> >> >>> I agree with your suggestion.
> >> >>> We would also need a way for the server to specify what type of
> >> >>> sorting it supports.
> >> >>> For example a readonly property: sortableFields and a property that
> >> >>> says how many sorting fields can be used.
> >> >>> Some servers may not support sorting at all (grep) or allow only
> >> >>> sorting on one field.
> >> >>
> >> >> I am also for this, although I think it is quite a big feature
> >> >> compared to our current freeze level.
> >> >>
> >> >> It is a good point you raise Jos. I do however think that it might be
> >> >> acceptable to require the servers to be able to sort the hit data.
> >> >> Otherwise one might have to pull massive amounts of hits over the
> >> >> wire only to get those with the highest atime at the top.
> >> >
> >> > Consider this thread bumped. It is our list of blockers I recently
> >> > posted about. We need a clear decision.
> >> >
> >> > I already made my point above.
> >>
> >> There has been some discussion on this on IRC which have led me to
> >> believe that the following solution would be optimal for all:
> >>
> >>  * Scrap sort.primary and sort.secondary.
> >>
> >>  * Introduce three new session properties:
> >>
> >>   - sort.fields a read/write list of fields to sort after, in that
> >> order. Default value ['xesam:relevancyRating']. The server should
> >> truncate this list to to the size specified in vendor.maxSortFields if
> >> too many sort fields are requested
> >>
> >>   - vendor.sort.maxfields a readonly uint. Specifies how many fields
> >> in sort.fields will be taken into account, as mentioned, sort.fields
> >> should be truncated at this length. This property must be 1 at
> >> minimum. If this value is 0 any number of fields can be used. Default
> >> value is undefined.
> >>
> >>  - vendor.sort.fields a readonly list of strings naming all fields the
> >> server can sort after. If this list is empty all known fields can be
> >> used for sorting. Default value is [].
> >
> > This parameter is superfluous. Suppose a client app determines the server
> > doesn't support sorting by required field. Either app has to do sorting
> > and doesn't really care about server sorting capabilities. If app doesn't
> > implement sorting, then the server can ignore fields it can't sort on and
> > that's all that can be done.
> >
> > Maybe there's another use case where app needs to know if server did sort
> > or not... I can't think of one atm.
>
> Consider this: A paged client showing 20 hits/page. If xesam:title is
> in vendor.sort.fields we make the list headers clickable so that the
> user can sort hits alphabetically by title. Combining this case with a
> result set of 50.000 hits should clear out the use case I think, I
> would rather not pull in 50.000 hits and sort them if I can avoid it
> (consider a grep-like or web-based server - although they may have
> problems in any case). Or maybe there is a clever way around this that
> I can not see..?

Clickable column argument does sound sane.

More likely than not we're going to see backends that don't sort at all like 
grep or db-driven backends that can sort all you want. The only possible gray 
area here are web services wrappers written by community... The services are 
very much likely running on top of a plain filesystem with no sorting or a 
db, but will they expose sufficient sorting capabilities?

-- Evgeny