Re: lynx-dev internal links

[Nelson Henry Eric]

> > one has mentioned that the (possibly) definitive discussion seems   
> > to be the 1997-11-03 entry in the CHANGES2.8 file.                  
>
> right - so (to the original point).  Shall we retain the feature, or
> not?  (Henry's response is still technically ambiguous - he stated
> lack of support, but didn't specify which alternative ;-).

I wasn't sure of the intent of refering to the 1997-11-03 entry in
CHANGES2.8.  If it means that people want --enable-internal-links, then
someone, not I, is going to have to speak up loud and clear in its
defense.

I apologize for having blown my stack.  I really am very sorry.  It's
just that I felt I was hearing in one ear "So, who's Fielding" and
"What's a 'draft' anyway", but at the very same time I was getting in
the other ear "Well, let's adopt Fote's interpretation because he's
_probably_ right."  It was either that or "Fote and Klaus were quibbling
about meaningless, esoteric semantics; both of them are gone now, so who
cares."  What indicated to me a lack of understanding of, or even worse,
complete apathy toward an issue at the very heart of a WWW client was
more than I could take.

My "technically ambiguous" position remains: if you are willing to spend
the time to back out Klaus' code, I say okay.

The reason is not that I think Klaus is "wrong" and Fote is "right."
I don't think it's such an easy black and white situation.  I do feel
(and I can't do much more than that since I am not able to understand c
code at that level of complexity) that when it comes to the parsing of
URIs, Fote, probably the only person in the world who at the stage of
Lynx2.7 had the _entire_ code set in his mind, had a better grasp of how
the parsing would interact with sensitve (security-wise) areas of the
code.  I also was convinced that Fote was interacting directly with Roy
Fielding in the very spirit of RFCs that you mention.  Finally, it was
my understanding (quite possibly wrong) that Klaus was relying on the
user to make the final decision if POST information in memory should be
sent to the URL that was resolved according to Klaus' interpretation of
how the parsing should be done, when indeed the RFC draft was not clear
in this area.  Maybe it's just because I'm in the same age bracket as
Fote, but I thought that was an awfully dangerous way to go.

But really, why ask a dunce like me?  Read RFC 2396, and if it's not
clear, or doesn't make sense to the point you can't write your program,
then comment on it.  That's what it's there for.  It is crucial for
software like Lynx to follow a recognized standard, otherwise how can
negotiation between client and host take place?  There really isn't a
lot of room here for ambiguity.

> > I assume you're still playing around with lynx's mail function.
>
> (I assume "you're" refers to Henry - I hope so too)

"I assume" that means that the majority opinion is that Lynx should be
released in the state that any idiot prankster can do what they jolly
well please.  Well, even if I am just one, I will voice my opinion one
final time that I think Lynx should nip such tricks in the bud.  Adds,
what?, 7-8 lines max to the code.

__Henry