LYNX-DEV responses

[Klaus Weide]

On Sun, 27 Apr 1997, Foteos Macrides wrote: [one long sentence which
I won't totally repeat :) ]:

>       [1] the extreme to which you are taking the issue of adherence
>           to standards, even when they disagree with what the great
>           majority of deployed browsers do (not just Netscape and
>           MSIE), and thus are of dubious validity within the IETF's
>           own requirements that it's RFCs reflect "consensus" and
>           formalize "current practice" (They are not commandments
>           written in stone.),

Yes, they are not commandments written in stone.  And we are mostly
dealing with just "Proposed Standards" anyway, subject to further review.

One reason I try to cling to standards is just that I need some guideline
when trying to understand the amount of existing code.  Well those
standards or proposed standards seem most fit for that purpose.  (I cannot
try to reproduce other programs' behavior and use that; I even know much
less of their behavior than probably many others here.)  So trying to use
the standards is a way for me to keep some kind of overview.  Every new
exception added to accomodate "current practice" of other browsers
usually adds more code, makes the code more unwieldy and difficult to
understand.  The amount of "extremity" you observe may just show the
degree to which I still feel lost without this orientation. :)

>       [2] the manner in which you are promoting them (which, IMHO,
>           penalizes the Lynx users by causing failures of access due
>           to sins of the document authors, rather than promoting
>           successful access coupled to statusline messages which
>           might help get the "bad stuff" in the authors' documents
>           corrected,

I don't see myself as much of a promoter, one way or the other.  I am not
always motivated by doing things for others ("the Lynx users"), but do
things that I find interesting.  I certainly hope that my stuff is useful,
or at least interesting, for others, and also try not to mess up
functionality that is there or changes that others make.  But the "Lynx
user" I know best is me.  (And in this case, this Lynx user thought that
he didn't want that change and that keeping the status quo of the
current code wouldn't be "penalizing" others.)

There you have some good reasons why I shouldn't be the sole coordinator
of this. :)

Anyway, your arguments certainly have merit, and I'll consider them again
(unless someone beats me to it). 
 
>       [3] the logic of your recent, substantial additions to the
>           devel code for resolving fragments, for showing just the
>           fragment versus full URLs in the advanced statusline or
>           showinfo display, and for regulating re-use of cached
>           HText structures (which in my view is flawed to the extent
>           of representing "serious bugs" in the devel code, and
>           increases the memory requirements needlessly, to do things
>           that often shouldn't be done),

Okay let's talk about this.  I was waiting for comments.  Also from
others who have tried the code, of course.

a) The "showing just the fragment" only makes visible that there is
a different handling, no problem getting rid of it.
b) where is the increase in memory?  please point it out.  I assume
you must mean something else than the code itself.
c) regulating re-use of cached HText structures.

When I started working at this stuff, Lynx would go out and make a new
request each time a user follows a link to HREF="#line123" in a document
which was the result of a POST (as an example.  Assume "safe" not set.
could also apply to result with no-cache header of a GET etc.).
This seems to have been so at least since Lynx 2.6, there were some
reports/complaints about it IIRC (although not many).  I could only assume
there was *some* intention behind it, for some cases.

So I set out to correct what appeared clearly wrong, without affecting
cases where the behavior might be intended.  Here is where
draft-fielding-url-syntax comes in, which you made the guideline for
handling fragment-only URL references in HTML.c (and which already adds
quite a few lines making the source more complicated).  It says:

   A URL reference which does not contain a URL is a reference to the
   current document.  In other words, an empty URL reference within a
   document is interpreted as a reference to the start of that document,
   and a reference containing only a fragment identifier is a reference
   to the identified fragment of that document.  Traversal of such a
   reference should not result in an additional retrieval action.
 
Lynx was already implementing one part of the special handling for
fragment-only references (don't use a BASE tag), but ignoring the other
(no additional retrieval action).  That seemed inconsequent and wrong (and
never intended by document authors).  So I tried to change it, but without
changing the cases the quoted paragraph does not talk about: references
which contain a (possibly relative) URL, possibly pointing to the same
document _and_ a fragment.

This means I have to distingush between the two cases.  For example, in
document http://a.host/a/path/a-doc.html, HREF="#retry" is different from
HREF="a-doc.html#retry" (with or without a BASE).  The first should never
"result in an additional retrieval action", the second might.  It meant
I had to propagate that distinction back up to mainloop(), and then things
got really complicated resulting in lots of changes.  It is very likely
that there are bugs and problems in that code, but your basic crticism
seems to be not with that but with the whole idea.

In fotemods, you have since significantly changed the rules, starting
with:
1997-04-20
* Mod in HTAccess.c to ignore the anchor's no_cache element if we're
  seeking a position in the currently loaded document. - FM

That is a more drastic change, because it affects both kinds of HREFs.
My, much more extensive, changes were the result of a more conservative
approach and being consequent about it.

So are you sure now that a "forward"-transversal (following a link, not
PREV_DOC etc.) in a-doc.html to a-doc.html#retry should _never_ result
in a new retrieval?  This might be a no-cache document, a POST from result
etc.  Then I am still wondering why the change wasn't made much earlier.

 -----
Well, this is getting verbose :), but your friendly criticism would be
more helpful if you also spent some more words on the "serious bugs".

   Klaus

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