Re: Inspecting options supported by plugins
- From: Iago Toral <itoral igalia com>
- To: <grilo-list gnome org>
- Subject: Re: Inspecting options supported by plugins
- Date: Tue, 19 Apr 2011 13:58:32 +0000
On Tue, 19 Apr 2011 12:16:17 +0200, "Juan A." Suárez Romero
<jasuarez igalia com> wrote:
On Tue, 2011-04-19 at 08:12 +0000, Iago Toral wrote:
As for the way plugin developers would provide descriptions of the
supported options I have a feeling that we should not use the XML
The reason is that the options that a plugin supports are set in
plugin's code not in some other file. It does not matter what the
file says if the plugin's code is not consistent with that. We
separating the implementation of the options from their definition
think that is not good, actually, we could very well have an XML
saying that a certain plugin supports options A,B,C and then the
code not supporting them at all because the XML file and the actual
do not match. I think this is a lot more likely to happen in the
go with XML files.
Yes, options are defined in plugins code. But it doesn't mean that
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
keys, not about other more complex things, like may_resolve() or
Sorry but I think this is a very bad idea. I said this so many times
already, but here I go again:
Let's focus on providing application and plugin developers with just
*one* way to do things that is clear and well known. We do not need to
provide two different ways of doing the same thing (and actually, this
is usually a bad idea that only leads to confusion). I don't like the
idea of some plugins using XML files to define options, others not using
XML at all and others maybe using it for some options and not for
others, we would be just messing things up for no good reason.
The XML would provide a default implementation for supported options
which, as I'm saying plugin developer can override if he wants.
I don't see the point of this, I really think we have more important
things to focus on right now than adding overriding capabilities for the
configuration, which btw, I thing is a very bad idea too.
I understand your pov that it would require plugin developer to
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
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().
Which is a lot more likely to happen if you have the definition of the
options in a separate XML file IMHO.
The rationale of the proposal is to make a better use of XML files,
free developer from writing boiler-plate code.
The XML files were defined for one very specific purpose and we do not
have to make "better use of them", they are good for what they were
intended to be, we do not need to force things into the XML just to make
a better use of them.
As for the boilter plate code, I don't care about that at this moment.
Plugins won't have dozens of options to begin with, it is not a problem
now and we can provide a good API in GrlCaps to ease this as much as we
Then there is also the fact that we should be getting rid of
declarative interfaces like supported_keys as we agreed when we
to have GrlCaps, so I think the definition of the supported options
should be done in the plugin code when defining its caps. Maybe
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
options provided by clients for specific plugins and seeing that
are actually supported.
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
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.
Yes, I really think we should not do that.
And as I said, I really dislike configuration overrides, in my
experience they are only good for messing things up.
] [Thread Prev