Re: Caps and Options update

["Juan A." Suárez Romero <jasuarez igalia com>]

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.

	J.A.