[Xesam] Sorting API to be more flexible

[Mikkel Kamstrup Erlandsen]

2008/6/29 Arun Raghavan <arunisgod at gmail.com>:
> On Tue, Jun 24, 2008 at 6:35 PM, Mikkel Kamstrup Erlandsen
> <mikkel.kamstrup at gmail.com> wrote:
>> 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 [].
>
> I think the proposal sounds reasonable. Beagle won't be able to
> support more than xesam:relevancyRating for now, AFAIK, but that's
> fine.

I think we have agreement on this. I have put it on the list of
pending changes for the next release (be that 1.0 or RC3):
http://xesam.org/main/XesamUpdates

So if nobody starts complaining this one will go in. Speak now or
forever hold your silence :-)

Cheers,
Mikkel