Re: lynx-dev dev17 clue?

[Klaus Weide]

On Tue, 23 Feb 1999, Henry Nelson wrote:

> ALL recent "features" should be off by default.  

I disagree with that as general rule.  Defaults are just that, defaults.
Supposedly they represent what a majority of users, or rather installers,
would want, to save them some work.  As long as something CAN be turned
off, there is no a priori reason why that should be the default - unless
it can be shown that most installers want the most "feature"-less version
possible.

For the *development* code there is another reason to have new features
enabled by default - they should be tested after all.

> Definitely, all
> so-called "features" should have compiletime options.  When something
> can't be turned off, it requires delving into the code.

It seems to me that that has been the case for most substantial additions.

> Lynx is getting way too big.  Lynx is no longer a valid option on a
> limited resource machine.  The real problem is that the code only grows.
> In the last two years, I don't recall the binary being smaller than the
> previously installed one.  It only gets bigger.

Some of that growth is due to more data, not more code - especially
more tables for charsets and entities.  Some is due to lots of small
changes that don't seem to deserve a #define of their own.  Some may be 
due to pervasive systematic changes (like for example changing temp 
file handling, introducing HTSprintf0 throughout the code) And I suspect
some is due to new "features" that you want and have enabled (and which
you would probably call features instead of "features" :) ) and to growth
within the code for those features.   Finally some "features" that
possibly should be #ifdef'd but aren't.

That's my completely unscientific survey; I won't go further into
speculation by guessing relative importance of those factors.

Henry, I think you must want *some* of those changes - otherwise you
would likey not follow the list, and would stick with some older version.
Should everyone who submits a change that could be regarded as a new
feature, even if it is either a small change or lots of small changes,
be responsible for introducing a new preprocessor macro?  Should Tom
be responsible for making all new code optional?  Such requirements
raise the barrier for contributions, and have their own costs (increased
size of source code, for one thing).

I suggest that those with a strong interest in keeping the executable
small should submit patches to further their goals, just like their
antagonists do. :)  If some parts of code need to be made optional in your
opinion, put the #ifdefs in, or if it's not that easy raise the issue for
specific code changes.

By the way, you mentioned only code size, but whether that is a good
measure depends on which resources are most limited.  What about lynx
needing more cpu time, or more dynamic memory and paging?  For example
static buffers are being eliminated, but now a lot more heap allocation
is needed.

   Klaus