2008/6/24 Evgeny Egorochkin <[EMAIL PROTECTED]>: > В сообщении от Tuesday 24 June 2008 16:05:54 Mikkel Kamstrup Erlandsen > написал(а): >> 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 []. > > 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 _______________________________________________ Xesam mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xesam
