[Insight-developers] Musings on new modularization

Johnson, Hans J hans-johnson at uiowa.edu
Sat Mar 12 19:54:45 EST 2011


First: I understand that modularization will eventually have benefits, and I am not opposed to it.  I loved my old comfortable ITK, and this new version is certainly going to take some time to get used to.

I do have a few observations that may/may not be addressable:

1)  Bad.  The path to code has a repeated name "src/ITK/ITK/Core/Common"  Note the ITK/ITK.  This makes it difficult to comminicate with other developers verbally when trying to work through problems.  "Goto the upper level ITK directory" "Goto the nested ITK directory below the ITK directory".   Perhaps this directory could be renamed back to Code, or some other unique name.  This should be done quickly before the developers fingers learn this pattern.  This is also annoying, because my shell prompt shows me the directory name that I am currently in, and with replicated naming scheme my current working directory displayed is now ambiguous.
1a)  There is "ITK/Utilities" and there is "ITK/ITK/Utilities" .  These should also be made unique.  Perhaps "ITK/BuildUtilities"

2) Unfortunate, but probably necessary.   Using grep to find items has become more tedious with the new "bush" structure, where the previous "tree" had fewer places to look. Not bad, and it is probably more annoying for those of us who have the ITK tree navigation imprinted as involuntary reflexes rather than conscious thought.   After re-trainging the new structure will likely make it easier to find items.

3)  Undecided.  Things are modular!  There used to be a nice fully connected build tree where one could select a branch and build everything under that branch.  This is no longer the case.  Upon entering the "Utilities" directory, I issued a make command, and was surprised that there was no Makefile there!  I see why this is the case, and perhaps someday I'll even appreciate this, but I was surprised by this and it will  require a change of work habits.

4) Good.  This is a good "annealing" code optimization process.  Shake things up and get us out of the local minima that we've been in for a while.  It is exposing some areas that where sloppy.  Honestly, considering the HUGE disturbance and the magnitude of massive change that just occurred, the smoothness of the transition so far is a testament to the quality of our overall processes and attention to detail.  We deserve a pat on the back for this.

5) This has always been there, but  it is more exposed now.   Do we really need all these different versions of the JPEG library?
Utilities/OpenJPEG vs Utilities/JPEG vs GDCM/jpeg

Food for thought.

Hans



________________________________
Notice: This UI Health Care e-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged.  If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution, or copying of this communication is strictly prohibited.  Please reply to the sender that you have received the message in error, then delete it.  Thank you.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.itk.org/mailman/private/insight-developers/attachments/20110313/b9ef9f07/attachment.htm>


More information about the Insight-developers mailing list