Plugins: BCOP, Options, Settings, Metainformation

[FunkyM]

I have an idea up for initial discussion (might move it to ML when I created an example based on this) which touches the whole plugin options/settings maintainability and might be a solution we all look out for.

Currently options and metainformation (plugin requires, always empty plugin info gconf key, allscreen/screen options, plugin name/description, group, etc.) are hardcoded. A gconf-dump plugin "extracts" that hardcoded data and generates gconf .schema files.

Due to targeting different formats to store the options depending on the plugin (gconf schema, ini file, plugin compiled option information, ...) it was apparently clear that options and metainformation about a plugin has to be stored in a more generic way.

One idea to overcome this was to provide a generic XML document to specify options of a plugin including some metainformation about these called BCOP (http://gitweb.beryl-project.org/?p=compiz/bcop;a=summary).

BCOP is a nice application which allows the plugin developer to define an .options XML file with a specific structure and use it to translate that .options file into either a gconf schema or C code to be included by the plugin. Thus the plugin developer only maintains a single file.

Remaining improvements in BCOP:
- BCOP is has a few minor structuring issues (group and subgroup elements? Could be fixed by defining a proper DTD ofc.)
- Only touches the options (the effect of this are issues we seen with defining right "groups" for plugins etc. and how a configuration app. deals with that information) while it seems perfect to store extended plugin information (and always requested by configuration tools)
- It does the work of a XSLT processor (why not rather use one then?)
- Does not provide translation features

The idea I like to propose is maybe even more general and attempts to solve some additional points that might be required and had been noticed on the ML's discussions on this matter.

Requirements:
- Single Storage for Plugin Metainformation (Name, Description, URL, Authors, Dependencies, Options, Resources, ...)
- Provide translation features
- Allow creation of all kinds of target formats out of that information
- Easily include the translation into the build process
- Enable configuration tools to get their hands on a lot of plugin metainformation in a general and simplified way
- Store relevant translation logic and metainformation where the plugin resides

Proposal:
- Create a XML DTD for a general plugin metainformation document (Store the Name, Description, URL, Authors, Dependencies, Options, Resources, ...; not only the options, think of a general plugin info file)
- Allow the individual keys to be translated using language identifier attributes (gconf schema XML like)
- Allow a plugin to supply custom XSL stylesheets which translates <plugin>.xml into <plugin>.<targetformat> (gconf would simply provide gconf-schema.xsl to generate it's language aware schema files, ini would have ini-file.xsl to generate ini files with sane defaults, an options-code.xsl would create the required C code for plugins
- Install format XSL stylesheets as part of -devel packages
- Use xsltproc in the build process (One liner: "xsltproc <stylesheet>.xsl <plugin>.xml <outputfilename>", you can even pass arguments to be used by the stylesheet dynamically with "--param setlanguage de" etc.)

This idea would basically move all the plugin metainformation and translation logic to the relevant part in the chain without the requirement to maintain a new application, rather the translation logic within the individual files.

It allows new future plugins to provide custom target formats or extend the current ones themself (without need to hack on BCOP; independence), it gives the plugin developer the benefits of metainformation we aimed for and allows extendability for the future.

How about an XSL stylesheet to automatically generate an HTML page of a plugin along all it's information (name, description, authors, list of options all in different languages) or auto-generate plugin documentation or send your plugin tarball to some online plugin database which reads your metainfo XML for information without you having to type it or ... ;)

We would build on the nice current BCOP work and create a general metainfo document format, then create appropriate XSL stylesheets for C-code, gconf and ini (I'll contribute of course) and alter the build process. Alternatively we could just extend BCOP with language features, agree on deveolpers to extend it if they need it and use it as an external tool in the plugin build process.

Comments?

Please don't argument over how I named stuff, the important part is the logic.

[mikedee]

Did you read the discussion on the mailing list. I think it was agreed that each option will get a metadata attribute which will be stored inside the code for most plugins. This could be provided as a separate file if needed.

From what I understand David is writing a gconf-dump tool of some sort to generate the schemas at compile time. You should post your requirements to the mailing list for discussion if you would like some of your ideas included ;)

[onestone]

We work currently on a complete new XML metadata description system (see ML). he new system will describe all options in a xml, so that we can then use xslt to generate gconf schemas ...

BCOP was not designed to do that much. BCOP provides a convinient system to handle options in a plugin. It is not a exact represantation of the compiz option system. It is designed to coexist with the current compiz option system. You can also use it only to add some new options to a plugin, and the old "hardcoded" will be still available.

FunkyM: XSLT is a nice turing complete transformation language. You can use it to create exacltly the same code as bcop, but you don't relly want ;-) (150 lines only to create the two Display and Screen option enums for the header)

[FunkyM]

Yes, I read the ML and this idea builds upon what had been discussed there.

(150 lines only to create the two Display and Screen option enums for the header)

I have extended XSLT experience and 150 lines (or less) would be the size for a complete stylesheet which would do complete BCOP .options to .schema translation. Such an enum creation is something around 10 lines only.

I'll try to create some example so people with less XSLT insight see what I am talking about and post that on the ML.

[FunkyM]

Looks like David beat me to it ;)

[mikedee]

If you are into XSLT, first see the doctor ;) - then feel free to generate an xml -> ini file parser.

This would be used to convert the xml in the same way but it would output files as per the ini plugin (they are very simple so it should not be too hard). It would only need to convert the option name and the default value.

At the moment ini needs to have systemwide files installed as the schemas are but its not vital so I have not rushed to do anything yet.