[Xesam] Sorting API to be more flexible

Mikkel Kamstrup Erlandsen mikkel.kamstrup at gmail.com
Mon Jun 23 15:04:31 PDT 2008


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.

Cheers,
Mikkel


More information about the Xesam mailing list