Re: Inspecting options supported by plugins

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

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

Well, I guess it depends on what you want to do in your application.

If you want to allow user to tune or set up options for current plugins
and future plugins showing them in a dialog, having a way of knowing
programmatically what are the options that plugins handles is something
needed.


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

Yes. After reading Guillaume's comment, I agree on this too.

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

Yes, options are defined in plugins code. But it doesn't mean that some
of the options can't be defined in the XML file. The point here is
providing plugin developers this option: they can define some of this
options in the XML file, but they can also do it in code. And I'm
talking just about the list of supported options, as well as supported
keys, not about other more complex things, like may_resolve() or
anything else.

The XML would provide a default implementation for supported options
which, as I'm saying plugin developer can override if he wants.

I understand your pov that it would require plugin developer to ensure
that both code and XML plugin matches, because it wouldn't make sense
telling in the XML it supports an option and then in code completely
ignore it. But I personally don't see it as a problem, because in the
case of defining everything in code it requires also developer ensures
that code for listing supported options returns options that are
actually supported and not ignored. For instance, in the case of
supported keys, once I forgot to add a key in the list of
supported_keys() that I was handling in resolve() and may_resolve().

The rationale of the proposal is to make a better use of XML files, and
free developer from writing boiler-plate code.

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

Yes, I agree. Not need to repeat again, but XML proposal would be
compatible with this: plugin developer could define the supported
options (and keys) using the grl_caps_add_config_option(), but also
using the XML file; in this case, Grilo would set the right config
option using the XML definition.

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

Yes, agreed.

Wrapping up, I think it would be good to provide a way of knowing
supported config options in plugins.

Regarding how to implement it from plugin POV, I think we should allow
plugin developers to do it either from code, or from XML (the first
would override the second). But that's my opinion, of course. If you
really think we shouldn't use the XML for this purpose, fair enough.

	J.A.