Re: Caps and Options update

[Guillaume Emont <gemont igalia com>]

On 05/04/2011 11:54, Juan A. Suárez Romero wrote:
> On Tue, 2011-04-05 at 11:32 +0200, Guillaume Emont wrote:
>> I cannot see the added value of this, and I can see two issues with
>> that
>> approach:
>>  - It would break modularity. Right now, Options depend on caps, but
>> caps do not depend on options (the implementation only depends on the
>> keys in grl-operation-options-priv.h).
>>  - If we only allow creation from that factory, we remove the
>> possibility of creating a caps-less options instance
>> (grl_operation_options_new (NULL)).
> 
> Aha, didn't know you can create options without caps. In this case, I
> agree with keeping as it is (and it also solves my last comment about
> obey_caps())
> 
>>>
>>> - In get_value() methods doc says applications and plugin developers
>>> shouldn't use those functions, unless they are defining custom
>> options.
>>> I understand then that our framework is providing specific API to
>> handle
>>> options defined by Grilo (like sorting or filtering) that will rely
>> on
>>> get/set_value(). Am I correct?
>> I am not sure I understand what you mean here. Could you clarify? 
> 
> In the current code, the only options we are handling are the flags and
> the pagination. And there is specific API to handle them. I understand
> that when we'll add sorting and filtering, we will add also specific API
> to handle them, even if internally they will rely on set/get_value(), as
> it is happening right now for flags/pagination.
> 
> My question is if in the future we add new options in the core, if we
> will add also specific API for handling then or not. If so, I understand
> that the reason to make set/get_value() public is for the case of a
> specific plugin wanting to add custom-defined options.

Yes, I'd tend to think we should add a specific API for each option.
Though if we end up with hundred different options, this might get
annoying, but I'm not sure we would get to that point.
The advantage of this is that it gives more flexibility on what we can
do for each option, and how we can modify it in the future (e.g. we can
add specific validity checks in the custom call).
> 
> 	J.A.
> 
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>