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

[Iago Toral <itoral igalia com>]

On Mon, 07 Mar 2011 13:07:55 +0100, Guillaume Emont <gemont igalia com> 
wrote:
> On 25/02/2011 12:18, Iago Toral Quiroga wrote:
> > El jue, 24-02-2011 a las 16:11 +0000, Lionel Landwerlin escribió:
(...)
> > > 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.

Yes, I think that would be a good idea.

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

I don't like this that much though, I think it would make the basic API 
more obscure.

Iago