Re: Operation options (filtering, sorting and more)

[Iago Toral <itoral igalia com>]

On Tue, 15 Mar 2011 17:47:21 +0100, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> On Tue, 2011-03-15 at 17:26 +0100, Iago Toral Quiroga wrote:
> > Notice that even though I proposed that I did mention that we should
> > support ranged dates :). There I was using things like this:
> >
> > min-date = X and max-date = Y
> >
> > so I only use the '=' operator from the API POV, but I am actually
> > doing
> > a < AND > comparison in the end. I think we need to cover this case
> > (and
> > maybe others) because it fits in what I would call "basic filters".
> > And
> > I mean the date filter case, not just any ranged filter like bitrate 
> > >
> > X
> > or something like that. Maybe duration could be interesting too, not
> > sure.
>
>
> Maybe having a RANGE operator would be enough. Something like:
>
> RANGE(min, key, max) ==> min <= key <= max
> RANGE(NULL, key, max) ==> key <= max
> RANGE(min, key, NULL) ==> key >= min
>
>
> 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

for example, but not:

grl_filter_set_ranged_filter and let plugins devs and pass users use 
this api to implement just any filter, because that is not what we 
wanted to do, right?

Iago