Re: [SrcML] new plugin handling and API structure

[Dennis W. <den...@in...>]

On Wed, 20 Apr 2005 19:47:29 +0200
Frank Raiser <fra...@in...> wrote:

> - New plugin architecture
 
> We want plugins to integrate as easily as possible, and therefore the
> current .srcml/plugin_type.xml files in which every plugin had to be
> manually registered for now should be replaced by a .srcml/plugins
> directory. The installation of a new plugin is then reduced to copying
> the plugin's .jar file into this directory.
Sounds like a good idea to me.

 
> The content of a plugin's .jar file should be a plugin.xml file and
> additional .class files for the plugin's implemented methods.
> Optionally source files or other helpful files may be included of
> course. The responsibility of the rewritten config handler will be to
> check the .srcml/plugins directory for any .jar files and read out the
> plugin.xml file from each. Now these plugin.xml files will contain a
> fixed meta-data portion as well as additional tags important for the
> individual plugin. Here's the common parts every plugin will have to
> include in it's plugin.xml definition:
> 
> <plugin 
>     name="plugin name" 
>     version="x.y.z"
>     homepage="http://find.the.plugin.here"
Instead of this attribute I'd rather have a new tag for custom
information and include a "homepage" tag in there. This can also include
author information etc. and make it more extensible.

>     type="parser"
>     classname="de.srcml.foo.Bar"
>     >
>   <authors>
>     <!-- typical authors markup. might be best if similar to docbook
>     -->
>   </authors>
See above

>   <dependencies>
>     <depends name="other plugin's name" version="minimum version of
>     plugin"/> <depends name="yet another plugin" version="u.v.w"/> 
>   </dependencies>
>   <!-- plugin specific information -->
> </plugin>
> 
> Plugins for all platforms (for now this includes API, Parser and View
> platforms) will then be loaded through a single method in the 
> de.srcml.config.PluginManager class. Here's a sample call to load the
> java parser plugin for the ParserPlatform:
> 
> Plugin p = PluginManager.loadPlugin(
>     "java", "0.1.0", PluginManager.TYPE_PARSER);
> 
> And here's what the PluginManager class will do with such a call:
> 
> 2) Once the correct plugin is found the dependencies will be checked
> recursively. To this end a dependency tree is built and topologically
> sorted.
I'm still not sure if a plugin will have more than one dependency to
other plugins. This is especially problematic because the only plugins I
can imagine working parallel are filter plugins which do not require a
stream if any kind and won't modify the underlying content.

> - new API structure
[...]
> So the idea is to get away from a monolithic API towards a pure plugin
> based API. A parser developer can then provide the neccessary API
> classes through an additional API plugin without having to sync with
> the SrcML team first. The actual API code will then be reduced to that
> of an APIPlatform only responsible for loading the neccessary plugins.
> Right now when a SrcML document is loaded with the SAXParser the nodes
> of the resulting DOM tree are replaced by nodes which are instances of
> the API classes. This substitution process will be described as part
> of an API plugin. so apart from the above mentioned meta information
> such a plugin will have to provide the API part of a plugin.xml also
> contains a matching table like this:
> 
>   <match name="if" class="my.own.If"/>
>   <match name="loop" class="my.own.Loop"/>
> 
> Now with the dependencies it is also easy to extend the API
> functionality by means  of a plugin. Suppose you have written an
> enhanced version of the If class providing more functionalities you
> want to use throughout several projects in your company you can simply
> extend your class from the existing one like this:
> 
> package my.own.improved;
> public class If extends my.own.If { ... }
> 
> And package it into a new plugin which apart from the mandatory
> meta-data only needs:
> 
>   <depends name="the previous plugin" version="x.y.z"/>
>   [..]
>   <match name="if" class="my.own.improved.If"/>
I've got a proposal:
(I'll currently ignore the plugins)
Why not make the matching table an extra file ?
This would - besides the "match" tag - include one or several import
tags: 
<import name="myBaseMatchTableFile" version="x.y.z">

Imports overwrite matching defined above them. This would remove the
ambiguity problem, which plugins have, for match tables.
Additionally developers can use this to - kind of - create a custom
"view" of the underlying srcMl tree. You'd have to call
SrcML.loadMatchTable(...) after loading the srcML file and before
actually letting the system replace the nodes.

 > Now we can take full advantage of the new PluginManager. First the
> dependency tree will be built. The first plugin will then be
> instantiated first and this means that the API will from now on match
> every 'if' tag with the my.own.If class. After that the new plugin
> will be instantiated replacing this match so that every 'if' tag is
> now represented in the DOM tree through my.own.improved.If .
I think "plugins" differ a bit from the matching which seems to me more
like a class bases structure (therefore the text above).
 
> Once this is realized applications can use whichever version of the
> API they require. All that is needed is a single line in the beginning
> telling the SrcML framework what the application expects:
> 
> Plugin p = PluginManager.loadPlugin(
>     "my own improved API plugin", "0.0.3", PluginManager.TYPE_API);
Hmm I'm not even sure if the thing we were discussing about actually is
a plugin. Of course a dynamic plugin structure might still be a good
idea.

-
Dennis