So far, plugins themselves don't register what are the options they expect from clients to be able to instantiate the sources. Instead, they just receive one or more GrlConfig from clients, which internally contains options and the values. The plugins just take those GrlConfigs, and check if the options they need are set or not.

How do the clients know what are the options plugins need or support? The idea were that each plugin would provide documentation about his purpose, and among other useful information, it would provide the list of keys plugin support.

Thus plugins would not provide a way to inspect what are the options they handle from a programmatically point of view.

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:

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.

From all the options, the one that I like the most is the second one: plugins can easily list there the supported keys, no need to write a single line of code for this, any developer can also read the XML in a easily way, and even if for some reason we go with third option, GrlOperationCaps could get the information from the XML file.

The drawback is that we would be making the XML file something more mandatory than it is right now.

Opinions?

If we go for an option that allows to retrieve that information programmatically, (either through an XML file or not), I think it is better to put it in the upcoming GrlCaps. Note that it's called GrlCaps, and not GrlOperationCaps, it is meant to handle all kind of capabilities of a source (not just stuff relative to operations). As we discussed on the mailing list, we will probably want to move things like _supported_keys() in GrlCaps as well; in that context, it would be more consistent to have the list of options in GrlCaps.

As for GrlOperationOptions, I can't see how they could help here, as they are operation-specific by nature.

Also, considering the nearing introduction of GrlOperationOptions, I think the name for stuff relevant to the plugin configuration should avoid using the name "options" to avoid confusion (therefore, if we go for 1/, I would advise to use a different name, such as _supported_configuration() or _required_configuration()).

(In reply to comment #2)
> If we go for an option that allows to retrieve that information
> programmatically, (either through an XML file or not), I think it is better to
> put it in the upcoming GrlCaps. Note that it's called GrlCaps, and not
> GrlOperationCaps, it is meant to handle all kind of capabilities of a source
> (not just stuff relative to operations). As we discussed on the mailing list,
> we will probably want to move things like _supported_keys() in GrlCaps as well;
> in that context, it would be more consistent to have the list of options in
> GrlCaps.
>

Yes, would make sense. Thus, GrlCaps would contain the API to introspect those supported configuration options.

Still, plugins could define their supported configuration options either programmatically (implementing the required functions), or through the XML. My first impression is that we should allow them both options: adding the options in the XML, but also having a way of defining them implementing the appropriate API. Thus, for most plugins the easiest way would be using the XML, while for other plugins requiring a more complex algorithm could implement the right functions in GrlCaps.

Of course, this could be done also for supported keys and writeable keys.

> As for GrlOperationOptions, I can't see how they could help here, as they are
> operation-specific by nature.

Yes. I wrote GrlCaps and GrlOperationOptions just to make reference to the work we are doing. But only GrlCaps would be involved in this bug.


> Also, considering the nearing introduction of GrlOperationOptions, I think the
> name for stuff relevant to the plugin configuration should avoid using the name
> "options" to avoid confusion (therefore, if we go for 1/, I would advise to use
> a different name, such as _supported_configuration() or
> _required_configuration()).

Yes, totally sensible.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/grilo/issues/18.