Re: lynx-dev dev17 clue?

[Jacob Poon]

On Tue, 23 Feb 1999, Larry W. Virden wrote:

> From: Henry Nelson <address@hidden>
> 
> > 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.

There is a downscaled Lynx called Bobcat.  However, it is not exactly
compatible with GPL (it must be used 'without charge', which is not true
in GPL). 

> Are you implying that we should be removing features as new features are
> added?  What features would you choose to remove?
> 
> The price of progress is growth.  But perhaps what is needed is a
> separated limited resource version of lynx that diverages somewhere along
> the release history at a version of lynx that is small enough, with work on
> applying only bug fixes that apply to that version, in a separate
> revision tree.
> 
> That way those who need to access the majority of the web will have the
> larger version of lynx, and those who have a small intranet application
> they need to support can use the smaller lynx - one without cookies,
> multiple language support, etc.

Another code split to Lynx?  Even though Lynx should be a lightweight
alternative to the big two (or 1.5 with Mozilla), by putting up another
variation over the primary Lynx sources in this stage, this may do more
harm than good.

Before Lynx can be downscaled, it needs a more scalable programming
architecture.  This way features can be better customized to suit the
needs of different hardware.  The URL-sensitive external application
support in Lynx is one way towards modularity, but it can be extended to
use internal Lynx libraries, or by extending its uses to handle
unsupported HTML/SGML/XML tags (instead of just MIME types).

However, such change to Lynx will take more time, but at least it will be
better than the temptations of code splitting, which had already happened.