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. Cheers, -- Arun Raghavan (http://nemesis.accosted.net) v2sw5Chw4+5ln4pr6$OFck2ma4+9u8w3+1!m?l7+9GSCKi056 e6+9i4b8/9HTAen4+5g4/8APa2Xs8r1/2p5-8 hackerkey.com _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
