<div dir="ltr">Hi OPS developers,<div><br></div><div>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.</div>

<div><br></div><div>In the course of investigating this, a number of scripting-related issues occur to me:</div><div><br></div><div>1) It would make most sense to use an existing script language, probably Jython, since it has the easiest syntax IMO.</div>

<div><br></div><div>2) But it would also be nice if ultimately the interpreter were script language agnostic, rather than tied to e.g. Jython only.</div><div><br></div><div>3) I couldn't find an existing project that provides a JSR-223-based script interpreter, but I did find a starting point at: <a href="http://stackoverflow.com/a/5598207">http://stackoverflow.com/a/5598207</a></div>

<div><br></div><div>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 <a href="http://dev.java.net">dev.java.net</a> (mirrored here: <a href="http://fiji.sc/git/?p=scripting/.git;a=summary">http://fiji.sc/git/?p=scripting/.git;a=summary</a>) that would serve as an excellent starting point for that.</div>

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

<div><br></div><div>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.</div>

<div><br></div><div>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.)</div>

<div><br></div><div>If you also agree with this intuition, then we might consider changes like the following:</div><div><br></div><div>* scijava-ops -> scijava-ops-OLD (or moved to "old-master" topic branch)</div>

<div>  -- preserve previous effort until all code has been successfully migrated out</div><div><br></div><div>* imagej-ops core framework -> scijava-ops</div><div>  -- the core framework is not image specific</div><div>

<br></div><div>* ij-core module framework -> migrate into scijava-ops</div><div>  -- that framework includes modules, commands, displays and widgets</div><div>  -- Christian asked me: why not move ij-core's module framework into scijava-common?</div>

<div>  -- I strongly considered that, but instead I think it fits perfectly into the OPS framework</div><div><br></div><div>* imagej-ops image processing ops -> stay in imagej-ops</div><div>  -- these ops are image-specific, and depend on ImgLib2</div>

<div><br></div><div>* imagej-ops widgets -> stay in imagej-ops</div><div>  -- and move Swing-specific code into ij-ui-swing</div><div><br></div><div>* ij-core scripting framework -> scijava-scripting</div><div>  -- scripting support is not image-specific</div>

<div><br></div><div>* ij-scripting-* -> scijava-scripting-*</div><div>  -- each of these has different, often very large, dependencies</div><div><br></div><div>* other ij-core unrelated stuff -> think more; consider case-by-case<br>

</div><div>  -- maybe some goes to scijava-common...<br></div><div>  -- would be nice if the "ij-core" module could completely go away</div><div><br></div><div>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.</div>

<div><br></div><div>What do you think? I am confident I could complete much of that restructuring very quickly (in 1-2 days).</div><div><br></div><div>Regards,</div><div>Curtis</div></div>