Re: [SrcML] new plugin handling and API structure

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

On Thu, Apr 21, 2005 at 02:10:03PM +0200, Dennis Waldherr wrote:
> On Wed, 20 Apr 2005 23:30:03 +0200
> Frank Raiser <fra...@in...> wrote:
> > 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.
> Information about author and homepage for example are not required for usual 
> operation of a plugin because it is content meant to be read by humans. 
> Therefore, instead of placing it at the root header element of the xml file
> a subelement would fit better.
> But this - I guess - is just matter of taste.

This makes sense of course. So let's try to keep the operation specific
meta-data within the plugin attributes and the parts most interesting to
humans separated from that.

So here's my current suggestion for the plugin.xml format which will be shared
for all kinds of plugins:

<!-- operational meta-data to create a unique identifier for this plugin,
to describe the type and provide a Class as entry point -->
<plugin
    name="some interesting name"
    version="x.y.z"
    type="parser"
    classname="foo.bar.Baz"
    >

    <!-- authors of the plugin -->
    <authorgroup>
        <author>
        <!-- 
        author content as described by docbook DTD:
        http://www.docbook.org/tdg5/en/html/author.html
        -->
        </author>
        <author>
        ...
        </author>
    </authorgroup>
    
    <!-- accompanying webpage - optional -->
    <link linkend="http://get.my.plugin/here"/>

    <!-- dependencies on other plugins - optional -->
    <dependencies>
        <depends name="other plugin" version="x.y.z"/>
        <depends name="another plugin" version="u.v.w"/>
    </dependencies>

    <!-- plugin specific content -->
</plugin>

> I meant especially an API plugin. But while normal plugins will usually have 
> more dependencies I'm not sure that there will be any topologic reorder at all.

While it might be true that for API plugins a topological sorting is
unneccessary I still think they should be treated just like other plugins.
Doing no topological reordering for API plugins creates a special case that
developers will have to be aware of again. I'd sacrifice this little bit of
runtime to sorting the dependency tree before I require developers to always
remember these plugins will be an exception to the rule.

> > Just a remark here: srcML is a project from kent.edu. We agreed on using SrcML
> > for our project to avoid too much confusion.
> I doubt it's really possible to avoid confusion much.

Indeed. It's a rather pathetic try to at least reduce the amount of 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.
> Since you save language type within a SrcML file you can load a default match 
> table given by that name. There is no inconsistency because loading a match table
> would not change the already loaded tree.

It's not getting inconsistent at runtime. I think the problem is that from my
point of view it is preferrable to keep a once loaded tree fixed. I believe it
will create too much confusion if your program decides at some point to simply
replace the tree with new nodes which essentially means that at this point in
the program the underlying API will be changed.

> But I guess there's no need to further discuss this matter as we already did that 
> personally.

Just to try summing it up for the other readers on this list it comes down to
a matter of personal taste. The question right now is which way will we go for
the actual implementation? I especially would like to hear other people's
opinion about this too.

> Yes and therefore no ambiguity because the import order of the xml file would
> not have bee changed whereas the loading order of plugins is dynamic.

Here we are at the point of either topologically sorting by plugin
dependencies or demanding the developer to specify the plugin load order. Once
more we have two different opinions here and it'd be interesting to get to
hear from a few more people.
There's also the option to mix both ideas. Let's say a plugin specifies two
plugins it depends on. Both plugins provide a similar methodology which could
cause ambiguity. While we could simply throw both of them into the dependency
graph and basically ignore this ambiguity letting either plugin win we could
honor the order these dependencies are listed in the plugin.xml by adding
additional edges to the dependency graph. In this case it would mean adding an
edge from the first plugin to the second to ensure the provided functionality
of the second will get overwritten by whatever the first plugin provides.
Therefore the plugin developer can specify the loading order dynamically.

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

When you have eliminated the impossible, whatever remains,
however improbable, must be the truth. ("Sherlock Holmes")