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

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

On Fri, 2011-02-25 at 12:18 +0100, 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.

It sounds good indeed.

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

We could provide the user a "tool" function which take his sorting
parameters and the source to query/browse/search, and do the filtering
on sorting parameters, that way the user can avoid warning messages from
the core and also be aware of dropped sorting keys (if he wants to
know).


> 
> 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
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list