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

[Klaus Weide]

On Sun, 20 Oct 1996, Hiram Lester, Jr. wrote:

> On Sun, 20 Oct 1996, Foteos Macrides wrote:
 [...]
> 
> > >What's the general feeling about updating the version string to 2-6-1?
> > 
> >     I think it would be a counterproductive "convenience" at this
> > time.  You'd be creating a new version without basic issues about how
> > Lynx development will be handled effectively, and what the objectives
> > and priorities will be, having been adequately discussed and clarified
> > yet.
> 
> I'm not really sure I see what you're getting at.  Since this code is
> primarily bug fixes for stuff that creeped into 2.6 (or has been lurking
> there all along <g>), I see that at some point we should freeze it at a
> 2-6-1 as soon as the patches settle down and give a fixed platform from
> which to base development on.  Otherwise it will be "2-6 is the latest
> version, but be sure to get the 'service pack' (Microsoft...<g>) as well."
> I see that as being even more confusing to have several versions of 2-6
> running around that perform differently.

It seems that one purpose of freezing this code set is solving some
user problems.  (The other purpose is giving Lynx developers/ hackers a
common base.)  That is, for example the next person who complain that
he cannot use certain services because of the POST redirect problem
will be told to use this code set instead of the current (official) 
Lynx 2.6.  Therefore we need to have a name for it.  For "internal
use" of lynx-dev developers/ hackers and faithful readers something
like "version 2.6 with the fixes applied as of <date> as is currently
available on Hiram's page at <URL>" might do, but not for talking with
the rest of the world.  Whether it is Lynx 2.6.1 or 2.6 PL1 or 2.6 beta1
I don't really care.

[...]

> >     Is there going to be an upgrade to, or at least substantive
> > adaptation for, the v5 Reference Library?  Are we going to keep adding
> > features that keep making the Lynx image bigger and bigger without any
> > clear overview or set of criteria for assessing their relative importance,
> > and how they affect Lynx users with limited resources?
> 
> I can't really answer that one.  I've been keeping an eye on my copy under
> Slackware Linux 2.0.0 (ELF binary), and it's only grown about 2k or so
> from my version with patches 1-5 and the nsl patch.  I do think that there
> has been some evaluation of wwwlib5 and its possibility of drawing Lynx
> closer to a DOS/Win32 port.

Well, I am "evaluating" (i.e. messing around with) wwwlib5.  I brought up
the idea that this may help for a Win32 port, but that was my idea, and 
the people who have tried to compile for DOS or Win (and even successfully,
in one case) seem to have done so without any wwwlib5. 
 
>                              I'm not sure how much larger that wwwlib5 is
> over our current one, but it would probably also make the step to HTTP/1.1
> much easier.

I couldn't tell you how much bigger the executable would become.  In my
current hacking code I am using Lynx w/ wwwlib5 and therefore HTTP/1.1.
But I have a lot of duplication of functions (old & new) and some 
unnecessary code[1] from the lib, debugging functions etc.  I also compile
with full debugging info, so the size of my image is useless to estimate
how big a Lynx-with-libwww5 after the necessary cleanup would be. 

> >     It might be better for things to stay a bit fragmented and
> > unclear, a while longer, while people are rolling up their sleeves and
> > getting hands-on experience supporting Lynx, as well as direct feedback,
> > themselves, on what they've contributed.
> 
> I think maybe I see your point a little, but the question becomes how far
> do we let the unclarity (is that even a word? <g>) go before we stop it
> and say "This is a release version and everything should be based on
> this"? 

There may be unclarity[2] as to where Lynx is going, what are the goals,
who is in charge, how to distribute etc.  But IF there is agreement that
the current code is recommended (at least) (a) for users with certain 
problems and (b) for hackers to base patches on, then this should be 
made clear. No need to let the general unclarity be reflected[3] in 
unclarity of naming that which currently exists.

   Klaus

[1] For example, my Lynx2.6/wwwlib5 has a persistent disk cache.
    A little time ago I have argued (together with Fote) that such
    a thing would not be necessary.  I still think so, but it was easier
    to include the necessary modules than to figure out where to comment
    out stuff. 
[2] Replace "confusion" if "unclarity" is not a word.
[3] I am not sure whether unclarity (if it exists) can be reflected.


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