[ome-devel] Client Architecture: A Proposal
Jason Swedlow
jason at lifesci.dundee.ac.uk
Mon Aug 23 23:34:08 BST 2004
Josh et al:
Apologies for the delay in getting back to you.
Your proposal is a good one, and worth considering, but I think runs
somewhat counter to one of the fundamental premises of the project.
OME is, initially, at least, about infrastructure. The whole idea is
to make an extensible system that can serve a number of different
requirement sets. First and foremost, we want to build the
infrastructure that serves as many microscope imaging applications as
possible (other kinds of imaging are possible, but one thing at a
time). In fact, we have built, starting with Ilya Goldberg's OME1.0,
infrastructure that actually makes new methods of inquiry possible.
The first version of OME, and all subsequent versiosn, have shipped
with a web-based client. It's not great, but it does allow data
management and visualization, and our latest version allows very nice
querying of analysis results. Starting last November, a few months
after the release of OME2.0, we began developing a different type of
remote client, as a Java application. The result is Shoola. Around
the same time, the VisBio project began integrating OME functionality
into their existing 5D Viewer, VisBio. Obviously your group has now
joined the party, around your pre-existing client, Tikal.
If one looks now at this array of clients, it all looks a bit messy--
why can't we get out act together, and make one client, that does what
"we" want? There are two reasons for this. First, there is a history,
as various efforts took off in various places. We couldn't know when
these efforts started what would work out, etc. So that's one reason.
But in fact, a much more interesting reason is that, in fact, this is
exactly what OME is about. Who are "we" and what do "we" want? Each
of these clients has been developed to serve local needs (local = a
lab). Shoola was built to satisfy requirements in our own labs
(primarily Dundee and MIT, and we are now modifying to support our
continuing efforts and to support very exciting work at Baltimore).
VisBio is being built at Madison, driven at least in part by the needs
of the labs there (Kevin please correct me if I am out of line here).
Each of us hopes to capture functionality of interest to a larger
community, but it probably is not possible for us, at this stage, to
make a fully-blown OME client. Frankly, a much more sensible way to do
this is to get some of the existing commercial clients (the product of
many many person-years of work) to talk to OME-- anyone from the
commercial community want to chime in here????. Where we DO need
harmony and cooperation is on the infrastructure and interface level--
thus all the discussion you have seen on this list. OK, maybe harmony
is a bit much to ask.
Here's another way to think about it. Our field desperately needs a
data model it can use to store and manipulate data, that includes a
reasonable level of extensibility. That is the heart and soul of OME.
But the client functionality that our two labs need are different
enough that keeping our two paths open is a good idea. This should not
be taken to suggest that every lab should define and build its own
client. But we do require the diversity we have to explore all the
things we can do.
Of course, there should be some convergence. At this point, I don't
think we are able to stamp a single client environment as "it". And
you are right-- there is a real cost in doing this. OK, maybe this is
all a bit misguided, and I am happy to be told so. The OME project has
just recently finished a massive effort to produce our first
semi-complete solution-- image data and metadata management,
interfaces, and Java and Web UI's. This is OME2.2. We are in the
middle of testing, patching, and using this and building our next major
release OME2.4. Here, finally, we will include all the major analysis
infrastructure **and** the tools to use it. Unfortunately, unless
someone drops another 15 developers on us (all contributions are hereby
solicited), our focus will be on those tasks. There will also be some
developments on the UI side, expanding the development of our Viewer
and Browser as well as a new Analysis client. In the meantime, there
are many side discussions on the inevitable rebuild of the server
architecture. 2005 is going to be a lot of fun!!!!
One more point-- you are right. If it has been done before, why do it
again? However, it is not clear to me that any of the tools you
mention actually contain all that we need. Maybe I am wrong here, but
if any of these have all the services, querying, etc., and performance
to handle our data, then let's explore it. From what I can find out,
it's not there, but I might be wrong. I am sure Ilya can add his 23
cents here.
OK, just my opinion. Again, sorry for the delay-- just the usual
overloaded list of things to do.
Cheers,
Jason
On 20 Aug 2004, at 16:19, Joshua Moore wrote:
> 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
> _______________________________________________
> ome-devel mailing list
> ome-devel at lists.openmicroscopy.org.uk
> http://lists.openmicroscopy.org.uk/mailman/listinfo/ome-devel
>
NOTE NEW EMAIL ADDRESS: jason at lifesci.dundee.ac.uk
**************************
MSI/WTB Complex
The University of Dundee
Dow Street
Dundee DD1 5EH
United Kingdom
phone (01382) 345819
Intl phone: 44 1382 345819
FAX (01382) 348072
email: jason at lifesci.dundee.ac.uk
Lab Page: http://www.dundee.ac.uk/lifesciences/swedlow/
Open Microscopy Environment: http://www.openmicroscopy.org
**************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 8746 bytes
Desc: not available
Url : http://lists.openmicroscopy.org.uk/pipermail/ome-devel/attachments/20040823/8054af2b/attachment.bin
More information about the ome-devel
mailing list