FAST - enable by default?

[Zhanna Tsitkova]

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


On Apr 6, 2009, at 8:21 PM, Sam Hartman wrote:

>>>>>> "Zhanna" == Zhanna Tsitkova <tsitkova at MIT.EDU> writes:
>
>    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