Re: lynx-dev when, where, why "kb/sec"? Any votes for a "simple" Lynx

[dickey]

> > Read 4 KB of data. 4 kb/sec. 
>  
> Not fair for me to speak up at this stage of the game, but for 
> my Internet connection this kb/sec "feature" is superfluous 
> (usually sits at 0 kb/sec; got up to 2 kb/sec once, but that 
> was only because I was rocking in my chair encouraging things). 
> Is there anyway to compile for the old-stlye data counter? 
> Seeing the bytes click over is enough to know what the speed 
> of transfer is. 
it's in one place, so I suppose we could add an ifdef.  I made it a
single function to make it simple to change.  (yes, it makes the program
a little larger, but it doesn't hit performance).
  
> Finally having been able to compile a development version (22), 
> it seems as if a few other little changes like this have crept 
> in.  It would be a lot of work to do if done all at once, but 
> I wonder if we could establish a BARE_BONES symbol that would 
> be a kind of generic symbol to not compile in simple cosmetic 
> changes which add code, no matter how miniscule.  It might be 
> a way to rather painlessly slow down the creaping bloat of Lynx, 
> which is becoming a major problem.  It is a fact that the Lynx 
> image on my SunOS has grown *FIVE* times what it was a little 
> less than 3 years ago.  Having a generic symbol that anyone could 
> wrap their new code in might be convenient.  In the future, a few 
> other obvious chunks not yet under control of compile options 
> could be added on. 
most of the growth afaik is the character-set stuff (a little hard to
disentangle).  The development Lynx's within a percent or so of the 2.8
version in size.
  
> If there is any interest in this, I might start with the tiny 
> piece that I added to avoid the need for a separate lpansi 
> program.  The BARE_BONES (open for suggestions for a better 
> name!!) symbol would in this case remove the entire "case 
> TO_SCREEN" in printfile() and all other associated definitions 
> and code.  I would probably go ahead and tie in what I know 
> how to cut out easily, e.g., news.  In months to come I would 
> then slowly plug away at the many hints Klaus gave me in the 
> past (ca. Oct. 1997) about reducing the image size. 
ok (in principle).  it'll make the code more complex though, unless
things are hidden away in macros.
  
> The advantage to this system, if you understand what I'm hinting 
> at, is that it would greatly reduce the complexity of the ifdefing 
> and would only require one generic message to pop up to explain 
> why the user couldn't reach the feature.  The disadvantage would 
> be that it would be all or nothing, i.e., you couldn't pick and 
> choose among the many tiny features that would be knocked out.  An 
> example of where this might really bug people would be that I'd 
> probably clobber one of `list' and `history', but what I chose to 
> be the less "necessary" and take out of the "small" Lynx, someone 
> else might think was indispensable.  Another example would be the 
> chartrans tables, but I'd probably confer with the list to get a 
> compromise on a small set. 
>  
> Would appreciate feedback on this idea.  If it seems to be a "go 
> ahead", we'd be looking at mid to late December for the first attempt. 
>  
> __Henry 


-- 
Thomas E. Dickey
address@hidden
http://www.clark.net/pub/dickey