Re: Caps and Options update

[Guillaume Emont <gemont igalia com>]

On 05/04/2011 11:30, Iago Toral wrote:
> 
> On Tue, 05 Apr 2011 10:48:32 +0200, Guillaume Emont <gemont igalia com>
> wrote:
>> On 05/04/2011 09:51, Iago Toral wrote:
>>>>  - for the options and caps that are defined, I think we should have
>>>> default values. I'm still hesitating on whether to put that in
>>>> initialisation or in getters.
>>>
>>> I don't get to see the reason, in which situation do you think default
>>> values for options/caps would be interesting? From what I see, when a
>>> cap is not set it can only mean that the source does not support it (so
>>> no need for a default value), and when a option is not set it can only
>>> mean the client is not interested in that option at all (so again, no
>>> need for a default value).
>>
>> The reason is that I need to return a value for functions like
>> grl_operation_options_get_flags()/grl_caps_get_flags() (getters of
>> values that are not pointers, where we cannot return NULL). Otherwise,
>> we would need to modify the prototype, with something like:
>>
>>   gboolean grl_caps_get_flags (GrlCaps *caps,
>>                                GrlMetadataResolutionFlags *flags);
>>
>> or
>>
>>   GrlMetadataResolutionFlags grl_caps_get_flags (GrlCaps *caps,
>>                                                  GError **error);
>>
> 
> aha, I see now.
> 
> I think my previous point is still valid, if a particular option/cap
> does not exist it should not have any default value, that would be
> misleading I think. Probably the API should tell the client that the
> option/cap is not defined.
> 
> Now, in general I think of caps more like TRUE/FALSE properties telling
> if certain capability is supported by the source or not, in that case
> FALSE should be the default if a particular cap does not exist (== is
> not supported)
> 
> In case we do need caps with values other than a gboolean, then I'd have
> the get APIs return a gboolean as you suggest above.
> 
> BTW, do we have an example of a cap that actually needs a value that is
> not boolean? (ignoring skip, count and flags which I think should not be
> considered caps, but simply options).

There might be a need for one for filtering

> 
> In the options department though, things are different, since here is
> not about stating whether a particular feature is available or not
> (TRUE/FALSE) but to actually provide and get a specific value to be used
> for that option. In this case, just as I suggested above for the case of
> the caps with values, I would go with a gboolean result to give feedback
> on whether the option is actually present and has a proper value.
> 
Yeah, I think I will go with the boolean result and pointer as parameter
 to return the option.