[Xesam] Sorting API to be more flexible

[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..?

Cheers,
Mikkel