No subject

SNAP only include (directly) 140 of those headers.

(the list is attached to this email for convenience)
( interestingly, 16 of those 140 are ImageIO classes )


so,

                  SNAP uses about 1% of ITK


Granted,
those 140 headers probably pull in another 200..(maybe ?).
but still, that will make about 3~4% of ITK.

----

In the case of Slicer3.6:

There are 467 ITK unique headers included in its source code.

               So, Slicer uses about 30% of ITK.


This list of headers is also attached to this email for convenience.


---------------------------------------------------------------------------=
------------


The rationale for modularization derives from this graph:

http://public.kitware.com/pub/itk/InsightStatCVS/loc.html

Essentially:

                       ITK has Linear Growth

The toolkit has consistently increased in number of lines
during the past ten years.  We have every reason to think
that it will continue growing at a similar rate for the next
ten years, as more specialized algorithms and classes are
added to it.

In particular, as we reach out to the application domains
of microscopy, remote sensing and computer vision.


Here is already the bump in growth for 2011:

http://public.kitware.com/pub/itk/gitstat/ITK/lines.html

As more code is added to the toolkit, it becomes harder
to distribute, tests, and maintain.  Modularization is one,
among many other (as you point out), approaches for
letting ITK continue growing without getting out of hand.


The immediate goals for modularization are:

1) Find / label / remove the trash in ITK.


2) Organize the ~2,330 files into conceptual cohesive groups.


3) Test and label each group according to measures of
    quality control : Code coverage, correctness, style,
    dynamic testing, documentation...


4) Raise the quality bar for critical components.

    For example, the itkObject must have 100% code coverage,
    while we could live with the Blox classes having 30%.


5) Maintain that level of quality as more code is added to the toolkit.


6) Facilitate the use of Add-ons with ITK without having to
    include them in the toolkit.

    So a specialized module that INRIA may create, could be
    distributed as a module that specific application developers
    can add to their ITK installation as an extra module.

    The same way that you can install extra packages in a Linux
    distribution, or R-packages in an R installation, or extra packages
    in a Latex installation, or extra toolboxes in Matlab, or extra plugins
    in Firefox.


Points (1-5) relate quite closely to Six Sigma methodologies

        http://en.wikipedia.org/wiki/Six_Sigma#DMAIC

that you know better than any of us.

They map to :

Define,
Measure
Analyze
Improve
Control

---------------------------------------------------------------------

Modularization is a common design answer to the
problem of managing complexity and growth.