Re: RFC: Operation Options API proposal

[Guillaume Emont <gemont igalia com>]

On 29/03/2011 14:46, Juan A. Suárez Romero wrote:
> On Tue, 2011-03-29 at 13:35 +0200, Iago Toral Quiroga wrote:
>> I have a feeling that we may need to extend/change the API to have
>> explicit support for multi-valued options. Having a single "filter"
>> option with various values (each an independent filter) looks like a
>> cleaner way to go about filters to me and I guess the idea of
>> multivalued options in general makes sense.
>>
> 
> Uhm... I think I'm not getting what do you mean by "multi-valued
> options".
> 
> Do you mean setting for instance a filter with with ARTIST and ALBUM in
> just one call?
> 
> 
>> If we go with the more generic approach to filters, then I guess the
>> "value" part of grl_add_option should be some complex data type, some
>> GrlFilter instance or something like that. And we would have it
>> subclassed for things like ranged filters, equal_filters, etc not
>> sure,
>> but this is something you guys have to figure out to test if this
>> whole
>> API makes sense :)
>>
>> With the less generic approach, the client API side of things is
>> clear:
>> they do not have to see any GrlFilter things or anything because they
>> have specific APIs tailored for specific supported filters, but we
>> still
>> need to figure how these APIs store the data of the filters in the
>> GrlOptions objects at least.
>>
>> Also, in both cases we also need to figure out how the
>> GrlOptions/GrlCaps objects would store the info about the various
>> different filter types and how plugin developers would get access to
>> them and identify them properly: that is, when in a plugin code I get
>> the value of the "filter" option and I get something (a pointer?), how
>> do I figure what kind of filter that is and how I should use it.
>>
> 
> Well, that is why I showed the doubts.
> 
> The generic GrlOptions is used to store pairs of <key, value>. To be
> honest, I'm not sure if this is too simple for our requirements.
> 
The helpers function _get_value() _set_value() *allow* you to store
(key, value). If you think the needs of your option are not fulfilled by
that, you can add things in ->priv.
GrlOperationOptions is mainly a placeholder for options you want to pass
to operations (hence its name), but any API that makes sense can be
added, and it can (should) be implemented in a clever way inside the object.

The get_value()/set_value() is a helper for the options that fit in its
case, and it is exposed to allow extensibility in plugins/applications
that do not (or cannot) modify core. Though maybe this feature is
overkill and we should not expose these methods.