[Xesam] Sorting API to be more flexible

[Evgeny Egorochkin]

В сообщении от 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.

-- Evgeny