Re: [Back on]: [RFC] Adding sort parameter

["Juan A." Suárez Romero <jasuarez igalia com>]

On Thu, 2011-02-24 at 16:11 +0000, Lionel Landwerlin wrote:
> > 
> > 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.
> 
> As pointed out by Iago in response to this mail, I don't think addind
> parameters is a good thing. We might want to provide a structure which
> contains all sorting parameters (just like for filters which is one of
> the topic at the moment).

I guess you mean "adding a GList parameter" is not a good thing, right?
Totally agree.

Because if you want to sort, i think either you need to have a parameter
in the function specifying the sort, or having some way of telling
source you want to sort results.

> 
> Also I don't think sorting with more than one key is highly interesting.
> And if you really want multiple key sort, then unsure it does not make
> the API usage more painful for single key sort (which is probably the
> most common way of sorting).

In my mind there is a statement telling "if you can sort by several keys
must not complicate the case of sorting by one key".

That is, if we provide API to sort by different keys, there must be
sugar API to easing sorting by one key, which as you say is probably the
95% of csaes.

> 
> > 
> > In some way, user is telling "please, sort by this keys, if you can".
> 
> Having some kind of flag telling whether or not the source is able to
> sort would be nice, so we can tweak the UI regarding want the source
> support.
> 

Yes, I think this is a must. Being grilo so dynamic, I think there must
be a way of knowing what sources support in run-time, to act
accordingly.

> > 
> > As example, I've added ordering support to Jamendo source.
> > 
> > Now, some questions/issues?
> > 
> > - Are this feature interesting?
> 
> If you're paging your results, yes, definitely.
> 
> > 
> > - 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.
> 
> Ascending/descending options is a non optional to me (is it for
> someone ?).

What is a must for me is that applications can be able to sort by some
key. For instance, sort by title, or artist name, or other key.

But to be honest, almost all applications I see so far sorts the result
ascending. So I don't know if we must allow applications to specify the
ordering. My opinion is that we should design our sorting mechanism
allowing this kind of specification.

> 
> > 
> >   * Should be enough specifying a type order for all keys, or should
> > each key have its own type order?
> 
> As said above, one key should be fine for 95% of users (maybe more).
> 
> > 
> >   * How to implement it (in core part)? Adding a new parameter?
> > 
> 
> I think it's request related, so yes one more parameter...
> 
> > 
> > As always, comments are welcome.
> > 
> > 
> 
> Regards,
> 
> --
> Lionel Landwerlin