Re: [SrcML] new plugin handling and API structure

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

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.

 
> 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 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.
 
> 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.
 
> 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.
But I guess there's no need to further discuss this matter as we already did that 
personally.

 
> 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?
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.
 
> 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.
Yes, thinking of that a plugin would make more sense for it.
 
> >  > 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.
My perspective doesn't require to change that. As we discussed those match
tags will be placed in the plugin's xml file. The plugin would be still the
same in both cases, it just would access it's configuration differently.

> > > 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. 
As before I was especially talking about API plugins - because that was actually
the whole instigator of this discussion.
 
> 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.
Yes, the ClassLoader will throw an error/exception when attempting to load the
class.

 
-
Dennis