Re: Inspecting options supported by plugins

[Lionel Landwerlin <lionel g landwerlin linux intel com>]

On Tue, 2011-04-19 at 08:12 +0000, Iago Toral wrote:
> 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.

I proposed to expose the options as a kind of "plugin property", but if
you think it fits better just in the documentation, I'm ok with that.
I'm just looking for a way to know how to feed the plugins (especially
the ones requiring login/password/apikey/etc...) without having to look
at the code.

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