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

[Lionel Landwerlin <lionel g landwerlin linux intel com>]

On Thu, 2011-02-24 at 15:50 +0000, Lionel Landwerlin wrote:
> Hello,
> 
> I think at some point having some sort of sorting parameters in the
> Grilo API would make sense. I'll describe my needs in following mail. I
> just wanted to start with the proposal from Juan from (already) 6/7
> months ago :
> 
> http://mail.gnome.org/archives/grilo-list/2010-July/msg00030.html
> 
> ==========================================> 
> 
> 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.

The sort feature would be quite useful in case you're paging your
results, otherwise you can still make a big request and sort everything
by yourself.


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

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

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

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

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