Re: Operation options (filtering, sorting and more)

["Juan A." Suárez Romero <jasuarez igalia com>]

On Fri, 2011-03-18 at 11:19 +0000, Iago Toral wrote:
> >
> > having it, I don't see why we need to restrict it to dates: we
> could 
> > use
> > it with other keys.
> 
>  Because the point of this the API is not to be a generic filtering 
>  mechanism, but support a set of basic filters that we think make
> sense 
>  for most sources, just as we would have, for example:
> 
>  grl_filter_set_type_filter
> 
>  we would have grl_filter_set_date_filter

And why we want to have a filtering by date but not a filtering by
bitrate, for instance?

I know that in your proposal you mentioned the date range, but not the
bitrate or other key case.

But I don't see why we need to restrict it if making it a bit more
flexible doesn't add a big penalty to implement it, specially when
sources are free to choose what keys they support in the range. If they
only support date, then good. But if they can support for other keys, I
think we should allow them to implement it.

If we want to add a specific filter for date, then the other filters
should be specific for each key too. That is, having a:

grl_filter_set_artist(...)
grl_filter_set_album(...)

And there is no filters for other keys.

Is that what we actually want?

In the implementation I started I'm more flexible than that, allowing
sources to specify which kind of keys they support on filtering. So if
they decide that can filter content by, let's say, license, then they
are free to allow users to do it. And the same with the ranges

Now, if you think that we must not be so flexible, then I'll change it,
but I'll deeply disagree :)


	J.A.