FAST - enable by default?

Sam Hartman hartmans at MIT.EDU
Mon Apr 6 20:21:21 EDT 2009

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

    Zhanna> Hmm... this brings us to the conversation about code
    Zhanna> modularity.  Thinking Kerberos Lite Client I'm coming from
    Zhanna> the opposite direction as one should have as small
    Zhanna> code/functionality footprint on the mobile device as
    Zhanna> possible. It would not be enough to identify just client
    Zhanna> vs server code - because some clients may need "server"
    Zhanna> functionality (U2U scenario) , but also allow customers
    Zhanna> pick up the functionality they desire for their
    Zhanna> client-to-be.  So, I suggest to restrict the functionality
    Zhanna> of the library during build time with such flags as
    Zhanna> NO_DES, NO_PKINIT, NO_RCACHE etc.

Note that the wider development community has not thought through the
small client design implications and has not been brought into the
mind set necessary for this.

I completely understand the urgency of the 1.7 lite client work.
however this was somewhat of a one-off.

To turn this into a change in design philosophy, I think you're going
to need to have a fairly broad discussion with the community where you
articulate and build consensus around the design goals.  You also
probably want to confirm some basic assumptions, like the assumption
that it is desirable to meet the needs of the general hosted community
and the small client community in one code base, rather than say
maintaining patches targeted for each mobile environment.

I think it is undesirable to start applying this sort of design to new
projects without clearly articulated principles and general agreement to these principles.

You've been thinking about this for a while.  Part of an open source
project is an education/common ground building exercise to build and
refine a shared understanding and to get everyone onto the same page.
That's the same sort of process needed to change long-standing assumptions like the minimize build time options assumption.

There are valid design tradeoffs associated both with the desire to
have small code in limited scope environments and with the desire to
have a uniform code base on hosted platforms.  Unless you build some
common understanding of the goals that this project has agreed to,
you're always going to run into a push/pull where different people
have different ideas about where to draw lines.


More information about the krbdev mailing list