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

[Guillaume Emont <gemont igalia com>]

On 25/02/2011 12:18, Iago Toral Quiroga wrote:
> El jue, 24-02-2011 a las 16:11 +0000, Lionel Landwerlin escribió:
>> 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.
> 
> That's true.
> 
> (...)
>> 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).
> 
> Actually, if we encapsulate the sorting parameters in one opaque
> structure and provide an API along with it, we can go from supporting
> just 1 sorting field to many just by adding new APIs without clients
> needing to adapt their code (just as we can adapt GrlData to support
> multi-valued properties).
> 
> Not an actual proposal but it would be something like this:
> 
> GrlSortInfo *info = grl_sort_info_new (key, direction);
> 
> Then we could have also APIs like this in the future if we want:
> grl_sort_info_add_key (info, key, direction)
> 
> And we would also have some APIs for plugin devs to get the info, like:
> grl_sort_info_get_key (info, &key, &direction) 
> 
> And also APIs for handling more than one sorting value in the future if
> we want that:
> grl_sort_info_get_key (info, i, &key, &direction)
> 
> I think this would be a good way to go about this.
> 
I agree, and I wonder if we couldn't merge that with filtering, and
potentially more things in the future. Expressing that with ideas of APIs:

GrlOperationOptions *options = grl_operation_options_new ();
grl_operation_options_add_sort_key (options, key, direction);
grl_operation_options_add_filter (filter);

That way, we could easily extend the options we support, without having
to break the APIs of _search()/browse()/... every time, we would only
need to add some methods on the GrlOperationOptions object.

Also, we could push the concept even further, and have the type of
operation (search/browse/metadata/...) in that same structure, so that
we wouldn't have _search()/_browse()/... but instead a
grl_media_source_execute_operation (operation).
But maybe that last idea is a bit far fetched.


Guij