Re: LYNX-DEV Update code and patches "RFC" :)

[Klaus Weide]

On Sun, 20 Oct 1996, Scott McGee (Personal) wrote:

> I was just thinking about what Fote was saying regarding continued addition of
> image bloating features to lynx. (I'm paraphrasing, don't bother to correct my
> statement unless I am WAY off in left field [that means "way wrong" for those
> not fluent with american cliches])
> 
> What struck me, is could someone (I assume someone means a person who is m
> motivated by having a system with limited resources and therefore motivated)
> look at lynx features with an eye to what can be left out to reduce image size
> 
> without overly reducing usefulness. That way, by coordinating with those more
> knowledgeble with the code, compile switches can be set up to help produce 
> such limited versions of Lynx.
> 
> What do you guys think? Is it worth investigating, or have I been up too
> late on a very bad day anyway?

Well, if it's worth investigating to you, I guess you'll go ahead and do
it.  :-)

I note that some none-essential features are already provided in this way.
I mean using "#ifdef"s in the code, so that unwanted code doesn't make
it into the final image.  Without closely checking the code right now,
for example DIRED support seems to work that way.  So does SLANG.  Or
other Lynx special like LYNXCGI_LINKS etc.  Other features that are not
used by everybody (e.g. traversal?) could be excluded in this way, but
I don't know whether it's worth the added complexity.

Anyway, I suggest that somebody really concerned about the image size
should try to build a minimal version (with DIRED etc. excluded), then
figure out whether the size savings are worth bothering.

I don't think it makes sense to conditionally strip down the SGML/HTML
parsing part of Lynx.  (But haven't really looked at it..)  Creating
Lynx binaries that understand only some part of HTML doesn't seem to be
right.

The architecture is modular enough that it should be very easy (i.e.
modification to the code required, but minimal) to leave out some
protocols..   For example, you know that you (or your users) never use
"finger:" URLs?  Compile a version without the HTFinger module.
The same for Gopher, FTP, News, probably even HTTP.  If you don't
want it, you don't have to include it in the binary.  To exclude one
of the Protocol modules, (1) exclude the relevant HTxxxx.o file from 
the "COMMON =" definition of ../Implementation/CommonMakefile, and
(2) edit HTAccess.o to take out the references to the Protocol module
from the lists of GLOBALREFs and HTRegisterProtocol()s near the top.
(Note: I haven't tried this.  Somebody willing to investigate should.
It just seems from the code that it should work.  Changes in more 
places would be needed to give users a sensible error message on
tryin to acces one of the omitted protocols.)

There seem to be some files in the .../Implementation/ directory whose
functions are not used by Lynx, but which still get compiled into the
libwww.a file.  Again, sombody more concerned with space saving could
investigate.  My current list of suspects has HTRules, HTAAServ, HTUU,
maybe more, but that is unverified.

Note that these may be in the libwww.a, but it doesn't automatically
mean they get included into the Lynx executable binary.  If no other
part of the code references functions from them, they are probably
excluded in the linking step of compilation.  For example HTRules.o
would get included into the binary because it is referenced in HTAccess.c.
There even is a macro in HTAccess that controls whether the reference
to HTRules is done or not.  Just compiling with "-DNO_RULES" (e.g. add
it to SITE_LYDEFS in the top Makefile) should prevent it.  Anyone
wanting to do size comparisons could start with this. Whether
HTRules is included or not, I could not find it being necessary 
anywhere in the code.

  Klaus



;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;