[ome-devel] Client Architecture: A Proposal

Joshua Moore j.moore at dkfz-heidelberg.de
Fri Aug 20 16:19:40 BST 2004


Ok. We've taken all of this a bit further and would like to make a 
proposal.

We originally came to OME because something good had clearly been
developed in the way of imaging databases. That was work that we
certainly didn't want or need to replicate. What we as admittedly
relative new comers to the project see now is a certain amount of
replication in the client side of things. Import code/regexes in Perl,
OME-Java, VisBio. Visualization in VisBio and OME-Java, and now in
Tikal. Differing extension/plugin frameworks. We're starting to reach, 
or maybe we have reached, a critical mass at which it will be difficult 
to merge and manage these pieces.

What we propose is to follow this general practice of building on
existing code bases and apply it to the client-side architecture. There
exist several platforms (whether "Rich Client" or "Rapid Application
Development") that provide such services: Eclipse, NetBeans,
Mozilla... We are most familiar with Eclipse and so will use it here as
an example (the choice of platform is not yet critical).

Using a platform like Eclipse would get us the following:
* An existing GUI which we don't have to maintain,
* and in which all our components can communicate through public interfaces;
* A clearly defined plugin architecture,
* possibly with automatic updates of changes;
* An existing user documentation system;
* A significantly smaller, more mangeable code base;
* A much larger community of developers and bug finders;
* And perhaps most importantly--it's is all documented with tutorials
which takes the burden of supporting new developers off of us.

What's obvious is that such a conversion consumes development time. We
(You) have already invested quite a lot of time into developing the
existing code base. Shoola is a sophisticated platform that we could
certainly development into a quite impressive client. However, do we 
consistently want to have multiple developers sitting on basic GUI 
maintenance.

There are several clients in addition to Shoola, VisBio, and Tikal that 
we can imagine fitting into this framework:
* Protege, an ontology tool which we're looking at for annotations. (A
Protege plugin for Eclipse exists in alpha form) 
http://protege.standford.edu
* myGrid, the bioinformatics client from the UK (It currently uses
NetBeans) http://www.mygrid.org.uk
* An LSID browser (though Haystack already exists for Eclipse,
http://haystack.lcs.mit.edu/)
* An annotation browser (Annozilla is a Mozilla plugin for 
reading/writing annotations, http://annozilla.mozdev.org/)

In the end, this allows the OME developers to not worry about menus,
tabs, interprocess communication, or how to package plugins, but rather 
to get to the job of visualizing and processing image data. The same of 
course is possible for VisBio. We at iBioS have now _twice_ decided to 
get out of the business of developing GUIs for lack of resources. Lesson 
learned: take what you can get for free!


--Stefan & Josh


More information about the ome-devel mailing list