Re: [SrcML] new plugin handling and API structure

[Frank R. <fra...@in...>]

On Wed, Apr 20, 2005 at 10:55:01PM +0200, Dennis Waldherr wrote:
> > <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

What kind of information are you thinking of there? I'd like to have the
meta-data part of the config.xml to strictly adhere to a XML schema to have a
common ground for plugins.

> > 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.

Yes a plugin will have more than one dependency. We already have that right
now. Consider a view plugin which is supposed to output plain source code. Now
we also need the PrintSelectionPlugin and the WhitespacePlugin for it to work.
And of course we want to use our own Input and Output Plugins too. So there's
already a whole bunch of possible plugin dependencies.
It shouldn't be much of a problem though to treat this more generally and 
support a complete tree (and including a cycle test of course). So I don't
really see a reason to restrict plugins to strictly depend on one other 
plugin only.

Actually I think just about every bigger plugin will need several other
plugins. Most plugins will make use of input or output plugins, they will
require parts of the API and in case of extending another plugin they will
also depend on that plugin.

> 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.

Just a remark here: srcML is a project from kent.edu. We agreed on using SrcML
for our project to avoid too much confusion.

What I really dislike about this approach though is the need to explicitly
call a loadMatchTable _after_ loading the file. So either you load the file
and there is no DOM tree created yet, then I consider this bad, as I only ever
want to write one line to get the whole tree set up from the file. And if the
tree is already created it would consist of dom4j DOM nodes and thus we would
have different kinds of trees before and after the call to loadMatchTable().
This is a design inconsistency I'd like to avoid.

I also don't see how the ambiguity is solved any different to the earlier
proposal. If I understood you correctly the extra file will contain the import
statements from several plugins in the same order as we would have gotten the
plugin instantiations through the dependency tree. Or what happens in case of
a plugin wanting to match 'if' to a class and another plugin wanting to match
it to another class? Won't it end up being the same with the more specialized
plugin overwriting the matching of the earlier plugin?

As for the custom view I don't think I really want to have that dynamically
available through a loadMatchTable() call. I'm not really fond of the idea
that the DOM nodes are exchanged, as this also exchanges the semantics and
available methods behind the nodes I can see that getting way too confusing.
If you want a custom view you are getting just that by specifying the exact
plugins you need for your view anyways.

>  > 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).

Indeed the matching part is a speciality of API plugins, but I try to think of
this plugin instantiation as a general mean for plugins to set up their
working space. If you think of something like Eclipse you could have a plugin
do simple things like adding its icons or menu entries to the program at the
time it gets loaded for example. Setting up the matching table is just the
equivalent of what an API plugin is doing to prepare its use.

> > 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.

In case of developing a new plugin you don't need such a loadPlugin()
statement of course, as it will already be loaded through the dependency
mechanism. 

But once you are developing a normal application there is no automatic
dependency checking and loading available. In that case the application itself
will simply try to load the neccessary plugins once they're needed. This would
even cut down on the size of published .class/.jar applications, as you don't
even have to include the complete API. Correct me if I'm wrong there, but it
should be possible to 'link' the application's .class files to the API
java/class files and then run the application without those other class files
being available (in the CLASSPATH). If this works loading the plugins through
the application will at least provide us with proper error messages. If it
doesn't we might have to think of another way of ensuring the enduser knows
what plugin is missing. A simple traceback that class ThisOrThat wasn't found
will not be sufficient of course.

-- 
Raiser, Frank
Student @ University of Ulm (www.uni-ulm.de)

When you can flatten entire cities at a whim, a tendency towards
quiet reflection and seeing-things-from-the-other-fellow's-point-
of-view is seldom necessary.
        -- (Terry Pratchett, Small Gods)