[ImageJ-devel] Module structure for OPS, and support for scripting

[Curtis Rueden]

Hi OPS developers,

Recently -- partially to help with debugging and partially because I think
it would be awesome -- I have been dabbling at implementing an "OPS
interactive interpreter" of some kind. This way, people can type in OPS
commands in an interactive way and play with stuff very easily without
needing an IDE. This would be even better than the ImageJ Script Editor
because it would give immediate feedback.

In the course of investigating this, a number of scripting-related issues
occur to me:

1) It would make most sense to use an existing script language, probably
Jython, since it has the easiest syntax IMO.

2) But it would also be nice if ultimately the interpreter were script
language agnostic, rather than tied to e.g. Jython only.

3) I couldn't find an existing project that provides a JSR-223-based script
interpreter, but I did find a starting point at:
http://stackoverflow.com/a/5598207

4) We are ultimately interested in adding more JSR-223-based scripting
languages to ImageJ -- maybe even more generally than ImageJ to the SciJava
namespace. There is an old project on dev.java.net (mirrored here:
http://fiji.sc/git/?p=scripting/.git;a=summary) that would serve as an
excellent starting point for that.

5) Right now we are implementing each scripting language as its own module
in its own Git repository; see:
https://github.com/imagej/imagej-scripting-scala,
https://github.com/imagej/imagej-scripting-r. I expect many more of these
will arise in the future as we support more languages.

So, how does that relate to OPS? Well, there is this open question of "what
should be part of ImageJ, and what should be part of SciJava?" We touched
on this in Konstanz but didn't really discuss.

The intuition that appeals to me is: if it is image-specific, it is part of
ImageJ. And if it is more general, it lives in SciJava. I like this
approach a lot because I think that in the long term, it will encourage a
larger developer community around the more general projects. (For example:
if all the scripting languages are branded as "ImageJ" then people not
interested in image processing may discard them out of hand when quickly
searching for solutions. SciJava strikes me as a much better level to focus
the scripting language projects.)

If you also agree with this intuition, then we might consider changes like
the following:

* scijava-ops -> scijava-ops-OLD (or moved to "old-master" topic branch)
  -- preserve previous effort until all code has been successfully migrated
out

* imagej-ops core framework -> scijava-ops
  -- the core framework is not image specific

* ij-core module framework -> migrate into scijava-ops
  -- that framework includes modules, commands, displays and widgets
  -- Christian asked me: why not move ij-core's module framework into
scijava-common?
  -- I strongly considered that, but instead I think it fits perfectly into
the OPS framework

* imagej-ops image processing ops -> stay in imagej-ops
  -- these ops are image-specific, and depend on ImgLib2

* imagej-ops widgets -> stay in imagej-ops
  -- and move Swing-specific code into ij-ui-swing

* ij-core scripting framework -> scijava-scripting
  -- scripting support is not image-specific

* ij-scripting-* -> scijava-scripting-*
  -- each of these has different, often very large, dependencies

* other ij-core unrelated stuff -> think more; consider case-by-case
  -- maybe some goes to scijava-common...
  -- would be nice if the "ij-core" module could completely go away

I know that such changes would rock the boat... again. But before we get
too much farther along I would like to have a very clear, sensible policy
which answers the question: "What is SciJava, and what is ImageJ?" And I
think the structure above would do that, and be a really strong foundation
for the next decade at least.

What do you think? I am confident I could complete much of that
restructuring very quickly (in 1-2 days).

Regards,
Curtis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20140329/3fd70a69/attachment.html>