[ome-devel] Client Architecture: A Proposal

[Joshua Moore]

Apologies if the grand proposal (our pre-weekend visions are always a 
tad optimisitic) seemed to say that the OME crew should be working on a 
one-stop solution for imaging. I in no way expect (or even want) this. 
In fact, though we'll be most likely be porting Tikal to Shoola, our 
other developers will continue hacking C.

However, as long as we're in the business of producing _any_ 
OME-certified clients, we should be careful to do it as efficiently as 
possible. As I mentioned, we've already been pushed out of the business 
twice for lack of resources.

I think the efficiency of such a platform shows up in two concrete ways.

The first is allowing for easy assimilation of other work. I can 
certainly understand that the VisBio group's not for a monolithic 
client, but the thought that a small plugin wrapper could let VisBio 
code run in Shoola is awfully sexy. Certainly a framework like Eclipse 
would facilitate this (there are any numbers of plugins which also 
function standalone.) And most immediately, getting Tikal into Shoola 
would also be simpler and would pose no additional overhead on anyone 
other than us. Plus automatic installation, update, etc. etc.

Further, if you imagine -- in our optimistic way -- that this process 
continues, and the masses come running to us with their code and want to 
have it in Shoola, then we better damned well be prepared for it. (To be 
a bit (a _bit_) more realistic: making the decision now to make Shoola 
more extensible might well save us a headache in the future.)

The second concrete point is something I think that those on the Java 
crew can speak to: how many times (per day) have you thought "If only I 
had more {time|developers} I'd X"? If this is something that comes up 
often and you're serious about it, then I think taking advantage of 
something like the Eclipse platform will make a big difference.

There are APIs for: optimized (i.e. JNI) filesystem operations, defining 
views, drag-n-drop, preferences, searchable help, login, caching, etc. 
etc. etc. All of the things that most GUI designers would like to get 
around to, but because of regular business can't. Plus a host of 
existing GPL'd code waiting to be used.

Eric Gamma (GoF, junit.org, Eclipse JDT) mentioned somewhere: “In fact 
when I think about it, there are not that many situations where I would 
favor implementing a Java application instead of implementing a plug-in 
for Eclipse.”

That might be a lot of hype, but when it comes to developing a fairly 
large system, having a stable infrastructure will make it go that much 
faster. I tried to look at the Shoola code to see what would have to be 
ported. Obviously, this is over-simplified but it looks roughly like this:

- all *.ui.* classes would have to be rewritten (There's the issue of 
JFace&SWT)
- each agents.* package would be wrapped as a plugin
- the env.* code would be a separate plugin called first.

Sure, this is not something that can be done over-night, and is perhaps 
even not feasible I can accept that. But as we plan for future versions, 
I certainly suggest that we examine it.

Yo. -J