Re: RFC: Operation Options API proposal

[Iago Toral Quiroga <itoral igalia com>]

El vie, 25-03-2011 a las 13:04 +0100, Guillaume Emont escribió:
> On 25/03/2011 12:47, Iago Toral Quiroga wrote:
> > 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?
> I don't know. But it could be anything the filter designer wants (Juan?
> reading this?).

Ok, Juan? :)

> >> 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?
> The name I proposed was caps_*can*_set_option, not caps_set_option. And
> yes, caps_test_option is indeed a better name, thanks for providing it.

Oops, I read too fast, sorry about that. Glad I contributed something
positive in the end anyway O:)

> > 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)?
> could be something like:
>   grl_caps_test_option_int (caps, "type-filter", GRL_FILTER_TYPE_VIDEO);
> (or would we need a test_option_enum?)

Aha, so for an artist filter we would have something like this then?
grl_caps_test_option_string (caps, "artist-filter", artist)?

> > 
> > And another question, how would the options get a reference to the caps?
> > 
> Two possible models (I plan to implement both):
>  - the GrlOperationOptions instance is created with a GrlCaps instance
> as parameter
>  - the GrlCaps passed to the constructor is NULL, no checks are made
> when calling _set_value(), the programmer should call
> grl_caps_fixate_options() before launching the operation if they want to
> know the options that will be honoured

Sounds good.

Iago