Re: Caps and Options update

[Guillaume Emont <gemont igalia com>]

On 05/04/2011 10:37, Juan A. Suárez Romero wrote:
> On Mon, 2011-04-04 at 20:14 +0200, Guillaume Emont wrote:
>> Some notes on it though:
>>  - I have put caps and pagination in the caps, even though they might
>> not be needed here (because we're likely to want these to be
>> mandatory).
>> This might change in the future, and is like that mainly to illustrate
>> how caps and options interact.
> 
> If flags and pagination are a must, I think there shouldn't be
> set_flags/pagination() methods, but instead setting them as TRUE when
> building the caps.
> 
I guess it's simpler and more consistent to just remove them altogether
from the caps.

> 
> Other issues:
> 
> - The same way we have GrlCaps, shouldn't be better to rename
> GrlOperationOptions to GrlOptions?
I actually hesitated between the two, and we could change that for the
sake of brevity. For the record, here are the reasons why I went that way:
 - Unlike caps, which typically would depend on a source (or maybe on a
(source and an operation), options are only related to an operation.
 - I asked that question on IRC, probably off peak hours, and I only got
one answer (from Lionel iirc) who voted for the more explicit version.


> 
> - grl_operation_options_new() requires a GrlCaps to build it. I wonder
> if it would be a good idea making GrlCaps a factory of
> GrlOperationOptions.
> Thus, instead of grl_operation_options_new() they would be
> grl_caps_new_options()

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)).

> 
> - 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?

> 
> - I'm unable to see the purpose of obey_caps() when
> grl_operation_options_set_value() is checking if value obeys the caps
> this GrlOperationOptions belongs to. Can you provide an example for its
> use?
If you want to reuse a similar set of options for a lot of operations,
with different sources, you can create it by doing
grl_operation_options_new (NULL). Then each time you want to refine it
for the caps of a given source, you use _obey_caps().

> 
> 
> 	J.A.
> 
> 
> 
> _______________________________________________
> grilo-list mailing list
> grilo-list gnome org
> http://mail.gnome.org/mailman/listinfo/grilo-list
>