I asked a question about this in one of my early notes, but I think it's important enough to have its own thread.
I view an extensible tool framework as a key piece of the archictecture. One way to make sure that this gets done and gets done right is to implement even the basic functionality as a set of plugins / tools for the core framework. This is the approach taken by Eclipse, so it would seem a natural given the heavy emphasis on Eclipse here.
Eclipse uses a relatively fine-grained approach which brings with it considerable complexity, but also lots of power. If you're off implementing the Foo datatype and I'm working on the Bar operation, we can plug them both in and they'll extend each other in addition to extending the core individually.
An alternative extension strategy could be "it's open source, just hack on anything you don't like," but this doesn't really work for anything more than trivial modifications and, in particular, doesn't scale well to multiple implementors extending functionality in multiple dimensions.
There actually isn't anything too magical about doing a good plug-in architecture. It's only a slight formalization of the design work that you'd be doing anyway for modularity and extensibility. The only real differences are: a) documentation and b) not cheating by using private mechanisms instead of extending the public interface.
At a minimum you want to be able to add reports, viewers, importers and exporters as coarse-grained tools, but I suspect that there's more power available by implementing more fine-grained interfaces.
Some of the Eclipse 3.0 updates make it a more generic platform and yes, possibly even a framework for an end user application (hmmm...)
As with most topics so far, the vision and the implementation are still far apart - something akin to Eclipse plugins is exactly what is needed, but I know the rough code we have so far does not come close to implementing anything like this yet. We do need to architect it properly and as you stated, be rigorous in using it our selves.
That little "hmmm..." worries me, so just to be clear, I was NOT suggesting that GeneaPro use Eclipse as its delivery vehicle in any way, shape, or form.
Why not use Eclipse as the delivery platform? You could use the new Rich Client Platform, but often when I'm working on genealogy I also create and edit other files not just my DB. I could see using Eclispse with the JDT stripped out. Then you already have a workable plugin architecture, a framework for docable views and perspectives, and way to organize genealogy projects.
Using the Eclipse Rich Client Platform (RCP) as the basis for the plugin architecture could be a possibility. The two potential drawbacks to be considered, in my opinion, are:
- the complexity of the plugin architecture
- constraints on the UI look & feel
The RCP is basically a stripped down platform which is new with Eclipse 3.0. It has all the IDE-ness refactored out so that it can be used to build arbitrary applications. For anyone with more time than I to evaluate it, you can find a FAQ and some tutorials here :
Having had a look at a lot of the Eclipse Documentation around Plug-ins, Perspectives and views, I think using the RCP could benifit this project.
I think one of the potential drawbacks Tom mentioned is infact a benefit. The fact that there is some constraint to the look and feel of an RCP project means it's one less thing to spend time agonising over.
The eclipse perspective model lends itself well to this project, as unless I'm mistaken the GENTEC model allready sees three distinct parts,
and these could be catered for as perspectives.
I feel that the plug-in architecture also fits with the idea of 'expert systems'.
And finaly the fact that there is a reasonably clear way of building and incorporatating things into plug-ins, and perspectives should give a good amount of stability to the whole project.
Constraining choice can certainly be a good thing given the right situation.
It's also possible that the complexity of the plugin mechanism could be dealt with by careful design of the extension points for the Geneapro core plugins as well as appropriate documentation.
The infrastructure that the Eclipse RCP brings with it has significant benefits in terms of not only UI components, but also other basic plumbing like software updates, documentation, etc.
Since both the benefits and the costs are significant, it'll take more than a cursory evaluation to figure out whether the costs or benefits are bigger. I haven't had time for more than a cursory evaluation, but if someone would like to write up the results of their evaluation, I'd love to read it.
I'm open to using RCP. I just haven't seen the data to support making a decision one way or the other.
RCP looks like it might be a good way to go, but I would like to take for a test drive. Has anyone tried to put something together using RCP?
Well I haven't done much since the weather got nice, but I did do some stuff that I didn't write up. Since it rained Sunday and Monday, I was able to go back and resurrect it.
I put together a simple RCP application consisting of the text editor demo with a GeneaPro splash screen and found it to weigh in at 7.5 MB (6 MB zipped) which is pretty hefty, but presumably the theory is that most of that 6-7 MB represents real functionality that would get used in the application eventually.
One issue I came across is that WebStart and Eclipse plugins are incompatible.
There are some workarounds here
which apparently depend on either crippling WebStart or Eclipse. Not sure what other options there are for easy deployment and installation. Of course, once the initial install is done, the Eclipse update mechanism can take over for some of the stuff that WebStart deals with.
I think I posted pointers to RCP tutorials before. There's a new one (in two parts) here, but you have to register with IBM:
The RCP does add a big chunk right off the bat, but I would be willing to bet it would be more size effective in a full blown app.
The Webstart issue is interesting - we have not defined a requirement that GeneaPro work via Webstart, since we've defined it pretty much as a standalone app. I can see where this functionality would be useful, and the workaround suggested to copy the entire environment locally via zip and then execute might work best for us. That defeats much of Webstarrt intended function and would really be just an alternate install method.
I've worked through the Eclipse RCP tutorial and will be banging on the IBM version next.
Log in to post a comment.