Code modularity

[Greg Hudson]

On Wed, 2009-10-28 at 11:33 -0400, Zhanna Tsitkova wrote:
> This is the initial write-up for the Code Modularity proj.

This didn't get any comments, which may mean that people didn't
understand it.  I'll try to rephrase the proposal in a different style.

Zhanna is proposing the following general plan for organizing functions
within a library:

1. We group APIs together if they are likely to be used together.  An
example might be init and free functions for the same data type, such as
krb5_c_init_state and krb5_c_free_state.

2. For every function in the library, we look at the set of API groups
which require that function in their dependency graph.

3. We put functions together in a file if they have the same set of API
groups requiring them.  Otherwise, we put them in separate files.

The payoff of this plan, as I understand it, is that every subset of API
groups will correspond to a subset of the source files within the
library.  For example, doing GSSAPI NFS in the kernel typically requires
the APIs to import a security context and wrap/unwrap messages with it,
but not the APIs to establish a context.  Currently, slicing up the
GSSAPI and krb5 modules to support that subset requires some pretty
major #ifdef surgery, but after this code modularity work, the surgery
would be limited to the build system--in theory, anyway.

One possible concern is that functions might need to move around
frequently because of external factors.  For example, if we add a new
API which uses some existing internal helper functions, a set of helpers
which previously lived together might need to be split apart (because
some of them are used by the new API and others aren't).  Such frequent
code movement could make it more difficult to look at the history of a
function's implementation.