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.
--Sam
More information about the krbdev
mailing list