Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El vie, 25-03-2011 a las 12:18 +0100, Guillaume Emont escribió:
(...)
> > What about a more complex filter like the ones I put as examples in some
> > other e-mail I sent to the list? Like these:
> > 
> > A filter with an argument, like:
> > Artist=X
> > 
> > A chained filter like:
> > Artist=X AND Album=Y
> > 
> > A ranged filter, like:
> > X < Date < Y
> I would see something like:
>  - caps store a list of arguments (or maybe a hashtable), as it would
> store any other value, on which we can filter, maybe with restrictions
> on them (can only be equal, or can only compare in a given direction,
> something like that)
>  - grl_operation_options_set_filter() (or _add_filter()) checks that the
> given filter obeys to caps (if non NULL), so does grl_caps_fixate_options().

What arguments would set_filter() take?

> Thinking of this, we want to write these checks in only one place. Since
> we need them both in caps and options, I think they belong to caps. So I
> think that over the stuff previously listed, we should add:
>   gboolean grl_caps_can_set_option (GrlCaps *caps, const gchar *key,
> GValue *value);
> And probably some helpers (_boolean, _int, _float and _string versions
> at least).

So caps_set_option would check that key/value are supported in caps? In
that case should it not be named 'caps_test_option' instead? Or maybe I
am not understanding its purpose well.... Also, what is 'key' and what
is 'value' in the case of a filter with no arguments? (Like the filter
by types you considered originally)?

And another question, how would the options get a reference to the caps?

> Also, maybe Juan can tell us whether the above model fits his ideas for
> filtering.

Yes, please :)

Iago