[MINC-development] Draft proposal for MINC 2.0

[Andrew Janke]

On Mon, 23 Dec 2002, John G. Sled wrote:

> Last time I was in Montreal, I had a chance to meet with Jason and
> Bert and put together an outline for MINC 2.0.  Based on that
> discussion, Leila and I have written a proposal outlining the
> requirements and design of MINC 2.0.  I've placed it on the web at
>
> http://www.bic.mni.mcgill.ca/users/jgsled/outgoing/minc2.0/
>
> Please comment.  I'm hoping that this will be the basis of
> a meeting in January in which we can all get together to hammer out the
> details.


Looks fairly complete from what I you have so far.  I get scared by the
statements in #4 though, this would insinuate that MINC2.0 is going to be
something entirely new.  Is there still sufficient interest in making MINC more
netCDF'ish?  Or has this dissapeared now?

Has OSX been dropped form the list of supported systems for a reason? :) I
get the impression that it will be platform of choice amongst "clinician"
MINC-users in the future with the niceties that it provides.

On the implementation side, how detailed do you want this spec to be?
If you want detail, I would like to have these included:

  * Support for a -version/-v option in all C/L tools.
      this may well clash with -verbose but that's life.

  * On this note, write down the standard args a MINC C/L tool should support
      Peter obviously had a list in his head when writing them and as such
      I attempt to follow his lead with new tools, but it isn't obvious!

  * Inclusion of a minc-config .sh script ala gtk/gsl/gnu stuff such that
      all a makefile need include is

    INCLUDES = `minc-config --cflags`
    LDINCLUDES = `minc-config --libs`

    Or perhaps go with the new style and use pkg-config aka GTK2.0
    This to me a far more elegant solution than distro-ing m4 macros
       to budding developers. (sorry steve!) pkg-config also just
       happens to be cross-platform.

  * Internationalisation (i18n) -- with the international use of MINC
      becomming apparent this should not be a hard thing to add.
    Especially with all the nice GNU gettext utils around for this nowadays.
    (Yes jason, viewnup is not a good example of this! :)

  * Finish of what Dave McDonald orginally intended volume_io to do, support
      multiple input formats, (but not OUTPUT formats! brough-ha ha ha!)
    If only the reading _in_ of ANALYZE/DICOM/ETC were supported world
      domination (and subsequent development) may happen sooner than you
      realise.

All in all a good read though!  Now get to coding it for me you lot! :)



'other interested party' member #12