[MINC-development] MINC 2 - re transitioning from MINC 1

[Jonathan Harlap]

Heylas,

Seduced by the exceedingly more user-friendly API of libminc2, I 
recently attempted to use it rather than libminc1 or volume_io for some 
new code I'm working on.  I felt it would be a good learning experience 
and that I might as well write code looking to the future rather than 
sticking with MINC1 forever.  My findings were somewhat disappointing, 
raising some questions about how people should be expected to transition...

1) libminc2 doesn't open minc1 (NetCDF-based) files.  I suppose that one 
could argue that being a new library for a new file format, it doesn't 
need to be backwards compatible.  However, if I write a new tool, I 
don't want to limit its functionality to a file format that hasn't yet 
been adopted.  So, I guess it's back to the minc1 library (meaning, 
libminc, not MINC 1.x).  Which is really disappointing, because the new 
API doesn't seem inherently incompatible with minc1 format files.  I'm 
curious if anyone out there actually writes code for libminc2?  Are they 
expecting that people will happily go convert all their data?  We have 
terabytes of data - converting it all would be fairly complicated, to 
put it mildly.  Not to mention, that even had we converted it all, as 
soon as someone runs a minc tool, odds are we'll have minc1 files again

2) The command line tools default to creating minc1 format files.  This 
seems really counterproductive - if I just upgraded from minc1 to minc2, 
shouldn't you be encouraging me to create minc2 files and require me to 
make a little extra effort if I still want to create minc1 files - as 
opposed to requiring me to make extra effort if I want to create minc2 
files?  This also extends to libminc, wherein unless I direct it 
explicitly, micreate will keep me with minc1 files if I pass it minc1 
files.  Actually, it'll even keep me with minc1 files if I call micreate 
before opening any other minc files.  This kind of behaviour seems 
designed to encourage people to continue using minc1 rather than getting 
them to start creating minc2 files and slowly weaning them off the old 
format.

3) The library has absolutely no error reporting from what I can tell. 
While testing my code and finding that a simple miopen_volume call 
failed on a file that other minc tools had no problem reading, it took 
me reading through the libminc2 source code to figure out why, because I 
couldn't ask the library what was wrong.  (Turns out I was naively 
trying to read a minc1 format file with libminc2...  See issue 1.)


I have to wonder what prompted these design decisions - am I missing 
some fundamental truth, or is libminc2 really meant to look good but not 
be used?  Are there any sites actually using minc2?  Are they actually 
adding -2 options to *every* command, or are they really just running 
MINC 2.x but only using the minc1 file format?  If the latter, then 
what's the point of MINC 2.x?

Cheers,
J