Re: Operation options (filtering, sorting and more)

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
a < AND > comparison in the end. I think we need to cover this case
maybe others) because it fits in what I would call "basic filters".
I mean the date filter case, not just any ranged filter like bitrate >
or something like that. Maybe duration could be interesting too, not

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:


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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]