Re: [RFC] Adding sort parameter

["Juan A. Suarez Romero" <jasuarez igalia com>]

On Mon, 2010-07-12 at 09:04 +0200, Iago Toral wrote:
> 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.

And this is what is happening right now: plugins sort results with their
own criteria.
> 

> 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.
> 

Well, to be honest, this is not the same at MAFW.

In MAFW, sort criteria was a string that plugins must parse in order to
know which type of sort should be used.

I think in this case is quite easier.

> 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.

We can add support to tell users which keys are we supporting in
sorting.

But my point was that if users are already living without knowing how
sources are sorting results, I thought that adding this parameter was
like saying "ok, I still know nothing about sorting, but if I can get
them ordered by this criteria, would be Ok".

On the other hand, if current sorting criteria is going to be written in
doc, I think we can do the same with the supported keys.

It must be notice that supported keys depends on the node we are
browsing. For instance, in the case of Jamendo, GRL_METADATA_KEY_ARTIST
is supported when browsing in 'artists' node, while
GRL_METADATA_KEY_ALBUM is supported when browsing in 'albums' node. It
is not easier to specify which keys support for each node; rather, I
would like to prefer having a supported_sort_keys() function, and then
let in the doc which of those keys are supported in each node.

> 
> 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).

I agree that for those 90% of applications what we have right now is
enough.

> 
> 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
> 

Yes, I'm aware of it, and this was one of the reasons to avoid the
"ASC/DESC" sort parameter.

Actually it is growing too much, and I was even thinking about having a
simplified browse function, in the same spirit as
serialize()/serialize_extended() case.
 
> > - 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.

This obviously heavily depends on your application. For instance, if
you're implementing a page-based UI, with "show prev/next results"
button, you would need to retrieve all results if you need to sort them
in a different way.

Moreover, even using treeviews or whatever, if results must be sorted
inside the treeview in the worst case user would need to wait until all
results are in the treeview to known that what he is looking for is not
among the results


> > - 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).
> 

Having asc/desc per key would be actually more flexible, but everytime I
think about it, the obtained interface is very nasty.

I wonder if having just one ASC/DESC for all keys would be enough for
99.99% of applications. 

	J.A.