[ImageJ-devel] Design meeting notes

[Curtis Rueden]

Hi Dscho,

When you write that you want to kill ij.io.FileInfo, I hope you meant
> "deprecate" instead. A number of plugins use this class.
>

Yes, sorry. The proposal remains to not change public API in ij.*, including
FileInfo. By "kill" I meant, "no corellary for FileInfo in the imagej.*
package structure." This is mainly because Bio-Formats provides a
generalized mechanism for solving the same problems (and more) that FileInfo
does.

Also, I am wary of the MVC design discussions. This all sounds as if your
> target was again a single-desktop application, and not an image processing
> library extensible via plugins which just so happens to also have an
> interactive backend for end users.
>

Unfortunately, the discussion wasn't well captured in the notes. Contrary to
how it might have appeared, I think the desire for an MVC design actually
illustrates our focus on "ImageJ as library." The reality is that much of
the engineering challenge of ImageJ *does* come down to how the GUI is
structured, since many developers do want to leverage portions of the GUI
(as a library) in their applications. So there are many layers to
consider...

In other words, I get the impression that not everybody understood what
> the @parameter design is about. It is not about making writing plugins
> simpler -- that is a side effect. It is solely to support CellProfiler,
> KNIME, cluster and grid execution etc.
>

I think Lee's quick usage of the design in CP definitely illustrates its
power and convenience. We can chat more in person when I visit.

Otherwise: impressive job.
>

I think the discussion served more to get us all on the same (or at least
similar) page, and thinking about these topics, than it did to make any
substantial design progress. We did settle on our priorities for the
conference presentation, at least, so that is good.

-Curtis

On Wed, Oct 6, 2010 at 5:42 PM, Johannes Schindelin <
Johannes.Schindelin at gmx.de> wrote:

> Hi,
>
> On Wed, 6 Oct 2010, Curtis Rueden wrote:
>
> > A few of us met for several hours today to discuss some design issues
> > for ImageJ 2.0. The original goal of the meeting was to begin defining a
> > new core class hierarchy corresponding to many of ImageJ's historically
> > most central classes: e.g., ImagePlus, ImageStack, ImageProcessor.
> > However, we discussed several other architectural issues as well. I
> > tried to take notes but they ended up being very terse. Nonetheless, I
> > wanted to mention their availability at:
> >
> >
> >
> https://docs.google.com/document/pub?id=13zVORIFldha5xT8C3wUPLPGr_ok30rh9whLrEsxYA_s
>
> When you write that you want to kill ij.io.FileInfo, I hope you meant
> "deprecate" instead. A number of plugins use this class.
>
> Also, I am wary of the MVC design discussions. This all sounds as if your
> target was again a single-desktop application, and not an image processing
> library extensible via plugins which just so happens to also have an
> interactive backend for end users.
>
> In other words, I get the impression that not everybody understood what
> the @parameter design is about. It is not about making writing plugins
> simpler -- that is a side effect. It is solely to support CellProfiler,
> KNIME, cluster and grid execution etc.
>
> Otherwise: impressive job.
>
> Ciao,
> Johannes
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://imagej.net/pipermail/imagej-devel/attachments/20101007/258f3a1a/attachment.html>