GNOME.org
 

Re: Inspecting options supported by plugins
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 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.
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 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().
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, and 
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 want. 


 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.


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. 

Iago
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]