Re: Caps and Options update

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

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.


Other issues:

- The same way we have GrlCaps, shouldn't be better to rename
GrlOperationOptions to GrlOptions?

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

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


	J.A.