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

[Iago Toral Quiroga <itoral igalia com>]

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.

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

I guess we would need to add some declarative interface ala
supported_keys() wich would default to a NULL list for sources that
don't support sorting.

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

Yes, probably this is a must have to have a proper functional sorting
feature.

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

With the example API I showed above, for this "one key" only sorting use
cases people would do:

GrlSortInfo *sinfo = grl_sort_info_new (key, direction);
and then pass sinfo to the browse/search and be done with it, looks
simple enough.

For the minority of cases where more keys are involved, they would use
something like grl_sort_info_add_key (key, direction) as many times as
they want, if direction is always the same, it is no big deal, if not,
they have flexibility to include the info without any significant extra
burden.

> > 
> >   * How to implement it (in core part)? Adding a new parameter?
> > 
> 
> I think it's request related, so yes one more parameter...

Yes, only one additional parameter encapsulating all the sorting
information and API along with it to interact with the opaque structure
holding the sorting info.

One additional thing we should figure is what will happen when users try
to use the sorting interface passing keys that are not supported for
sorting by the source.

I think the core should check the keys passed by the user against the
ones supported by the source and drop the ones that don't match (maybe
logging a warning or a debug message about it) before delagating the
work the plugin. This way we ensure that plugins only get keys they
support and do not have to check for this.

Another option would be to raise an error inmediately, but I think that
aborting a search/browse operation just because there are unsupported
sorting keys specified is a bit too much.

Iago