Re: Inspecting options supported by plugins

[Iago Toral <itoral igalia com>]

On Mon, 18 Apr 2011 18:29:43 +0200, "Juan A." Suárez Romero 
<jasuarez igalia com> wrote:
> Hello.
>
> Lionel filed a new bug about adding a way of knowing what are the
> options suppported by plugins:

(...)

> If we want to add API so clients can inspect the options a plugin is
> able to handle or even need, how the plugins should inform about 
> them?
> Right now, it comes to my mind several options:

Is it really needed? do we need to provide means to check the config 
options programatically?  I mean, that would be nice but I guess that 
only a tool like gst-inspect would make use of that, right? For regular 
clients I think it would be enough if they have proper gtk-doc 
documentation, which we should have anyway.

> 1) Plugins provide grl_metadata_source_supported_options() that 
> provides
> a list of the options supported by plugins.
>
> 2) Options are provided inside the XML file, with a brief description
> and probably some attributes telling if option is compulsory or not, 
> or
> the expected type. Roughly speaking, something like:
>
> <config>
>   <key type=string compulsory>
>     <name>password</name>
>     <description>User password</description>
>   </key>
> </config>
>
> Core would provide a set of functions to inspect that information.
>
> 3) Using the future GrlOperationOptions and GrlOperationCaps to do 
> it.
> Honestly, I'm not sure about this option.

If we decide that we need this, I'd do as Guillaume suggested in 
bugzilla and use GrlCaps to provide the API to access the configuration 
options available.

As for the way plugin developers would provide descriptions of the 
supported options I have a feeling that we should not use the XML file. 
The reason is that the options that a plugin supports are set in the 
plugin's code not in some other file. It does not matter what the XML 
file says if the plugin's code is not consistent with that. We would be 
separating the implementation of the options from their definition and I 
think that is not good, actually, we could very well have an XML file 
saying that a certain plugin supports options A,B,C and then the plugin 
code not supporting them at all because the XML file and the actual code 
do not match. I think this is a lot more likely to happen in the case we 
go with XML files.

Then there is also the fact that we should be getting rid of 
declarative interfaces like supported_keys as we agreed when we decided 
to have GrlCaps, so I think the definition of the supported options 
should be done in the plugin code  when defining its caps. Maybe some 
API like grl_caps_add_config_option() would do the trick.

Finally, if we add this API we should have the registry checking the 
options provided by clients for specific plugins and seeing that they 
are actually supported.

Iago