2008/6/29 Arun Raghavan <[EMAIL PROTECTED]>: > On Tue, Jun 24, 2008 at 6:35 PM, Mikkel Kamstrup Erlandsen > <[EMAIL PROTECTED]> wrote: >> 2008/6/24 Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>: >>> 2008/6/13 Mikkel Kamstrup Erlandsen <[EMAIL PROTECTED]>: >>>> 2008/6/13 Jos van den Oever <[EMAIL PROTECTED]>: >>>>> >>>>> 2008/6/13 Urho Konttori <[EMAIL PROTECTED]>: >>>>> > 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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
