FAST - enable by default?

[Sam Hartman]

>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:

    Zhanna> Well, another approach would be dividing the code into
    Zhanna> smaller files in such way that when constructing the
    Zhanna> client one would pick up the object files needed to
    Zhanna> fulfill the functionality requirement.  Basically, build
    Zhanna> the whole code, collect needed object files and then link
    Zhanna> them into the library/appl.  Thanks, Zhanna


If we could figure out how to make this work, I think it would be a good approach.

Basically what it would mean is that all you would need to do to trim
Kerberos for some environment is to patch function call tables.  It
would mean that as someone trying to trim Kerberos, you are
responsible for making the system as a whole be consistent.  

It would argue against linked function call tables.  For example,
having one big accessor would not be a good idea because keeping track
of what goes in that would be difficult.  But you could have an
accessor for GSS-API (possibly with a separate one for RC4) or
possibly one for GSS acceptors and one for GSS initiators.

But then the major trimming points would be tables of enctypes, the
export list from the libraries, and possibly a few others.

Even with this approach, there is a lot of work to do to design
current and future code so that you get optimal results when you trim
things.
However it seems like it would be more maintainable than a lot of other approaches.

--Sam