Re: [RFC] Adding sort parameter

[Iago Toral <itoral igalia com>]

On Thu, 08 Jul 2010 18:12:49 +0200, "Juan A. Suarez Romero"
<jasuarez igalia com> wrote:
> Hello, everybody.
> 
> It is well known that right now Grilo does not allow to specify a order
> when browsing or searching content; it is up to sources to decide if
> they want to sort results or not, and how to do it. If user need to get
> elements in a specific order, she need to sort them herself.
> 
> Nevertheless, some services allow to sort results when querying them, up
> to some degree. So it would be good if we can exploit this option and
> offer it to user.
> 
> Actually, this issue comes from Calvaris, as he told me about it when
> porting Grilo to Maemo5: when browsing through Jamendo source from
> Mediaplayer, all results were a bit randomly shown (well, in fact this
> is not true, as Jamendo is returning data sorted by rate; but from user
> pov, seem they are unordered).

Well, for the record, plugins should normally sort results if they can, the 
fact that the user does not have means to specify sorting is not a stopper for 
that. So in this case, Jamendo should be sorting already by title or something 
reasonable.

> So thinking about it, I have implemented a first preliminary version
> that, of course, need to be discussed.
> 
> Basically, a new parameter is added to browse(), search() and query()
> functions: the sort parameter. It consists of a glist of metadata keys.
> How sources process them? As usual, almost everything is optional in
> sources. In this case, source will pick the first key in the list that
> can be used to sort the results, discarding the other ones; if it needs
> or can sort by several keys, it would pick the next one, and so on.
> Obviously, if it doesn't support sorting at all, it will kindly discard
> all keys.

Obviously, if I wanted it to be like this I would have added it the first day 
:)
This is the MAFW way to deal with sorting and to be honest, I don't like it 
very much. That's why I did not add support for that back in the day. Maybe 
we can discuss now if there are better alternatives or if the feature itself 
is really that interesting.

What I dislike about this solution is the fact that users don't have a clue 
about what sorting keys are supported by the source or if sorting is supported 
at all. They just pass a set of keys hoping the source will know what to do 
with them and this keys. I feel like users should be notified of what sorting 
capabilities a source implements.

On the other hand, when I think about this, I always end up thinking a default 
sorting policy implemented in the plugin itself (what we have right now) is 
good enough for 90% percent of the applications already and if an app is really 
really interested in providing a different sorting, they can always do that 
in the app (things like treeviews support sorting).

Another thing I don't like too much is the fact that we are adding another parameter 
more to a quite big interface already but I guess that cannot be helped

> In some way, user is telling "please, sort by this keys, if you can".
> 
> As example, I've added ordering support to Jamendo source.
> 
> Now, some questions/issues?
> 
> - Are this feature interesting?

Of course it is, just that I think maybe it is not as interesting / useful as 
one may think when you consider that plugins should already be providing results 
sorted by the most appropriate field and that apps can already implement sorting 
in the UI.

> - Right now, in this preliminary version there is no way of telling if
> we want ascending or descending order. Jamendo plugin is implementing
> ascending order, and seems a good idea to specify it.

I guess that if we implement sorting we should provide that info too, otherwise 
our implementation would be incomplete.

>   * Should be enough specifying a type order for all keys, or should
> each key have its own type order?

If you really want to be flexible wrt sorting, each key should have its own 
sort type. Another thing that makes me thing that sorting does not deserve bloating 
the interface this much...

>   * How to implement it (in core part)? Adding a new parameter?

I guess, but if we need to deal also with asc/desc order then we would need 
two parameters (or a struct to handle both, which is the same in the end).

Iago