lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV responses


From: Foteos Macrides
Subject: Re: LYNX-DEV responses
Date: Mon, 28 Apr 1997 21:51:49 -0500 (EST)

Klaus Weide <address@hidden> wrote:
>On Sun, 27 Apr 1997, Foteos Macrides wrote: [one long sentence which
>I won't totally repeat :) ]:
>>[...]
>>      [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.
>[...]

        When you add elements to the document, WWWDoc, and/or anchor
structures, the allocations for them are retained in their stacks
or hash tables, whereas if you can get away with just functions, those
are loaded only whenever needed, without long-lasting allocations.  I
had long ago added an LYoverride_no_cache flag, in conjunction with the
handling I added for "Pragma: no-cache" or it's equivalent in HTTP/1.1
Cache-Control directives via http/https headers and/or META tags.
That acts in a complementary, coordinated way, with the
LYforce_no_cache flag, in situations where it's unwieldy to use the
latter, but do want to ignore no-cache directives, if they were
present, as when acting on a PREV_DOC command, or a link activated
via the History Page.  The vanilla code needed tweaks to use that
properly in conjunction with use of fragments for positioning within
the currently loaded document, so that they are equivalent to the
keystroke comments for movement within the currently loaded document.
The problem was not specific to replies from POSTs, though that is
the most common situation which brings out the inadequacy in the
vanilla code.  I had added a quicky fix in HTAccess.c, and then what
I think is a comprehensive fix in fotemods, with minimal additional
code and no additional long-lived allocations.

        Fragments are solely instructions to clients, not part of the
actual URL, and their presence or absence has no bearing on whether to
honor no-cache directives when retrieving from cache (in our case, any
HText structure which is not the one currently being displayed).  Also,
whether the URL was resolved with or without anything preceding the
fragment, and versus the current document's URL versus a different
Content-Base header's, META tag's, or BASE tag's value, has no bearing
on the matter once the HREF or SRC in the markup has been resolved.

        Your fragment handling mods and INTERNAL_LINK_ANCHOR stuff
go far beyond the issue of whether to back off from the Fielding
URL draft when a MAP does not appear above the IMG or OBJECT which
references it (see below), create long-lived allocations needlessly,
and are based on unsound logic which contradicts the above.

        For example try http://www.wfbr.edu/htbin/junk with the
devel code versus the current lynx2-7-1+FOTEMODS.  That returns
a "document" with a "Cache-Control: no-cache" header, a link
to capsule.html in our public http server's data tree, and has
two fragment-based links to the position of the capsule.html link
within the same document.  One of the latter two has just
HREF="#capsule" in the markup, the other has more than that, but
they both *resolve* to exactly the same URL plus fragment directive.

        lynx2-7-1+FOTEMODS treats them both as equivalent, and
will not act on the no-cache directive if either is ACTIVATE-ed
within that document (i.e., simply to reposition) but will if
either is invoked when another document is being displayed, as
it should, because you are retrieving from cache.

        With the devel code, the first, which had just "#capsule"
as it's HREF value, will be displayed in the advance statusline and
showinfo page as just the fragment, whereas the second, which had
more in its HREF value, will be displayed as the actual URL plus
fragment instruction, even though upon being resolved from the
markup they are *functionally* identical.  If you ACTIVATE the
first, you will be positioned at the capsule link without acting
on the no-cache directive, as should happen, but if you ACTIVATE
the second, the devel code will act on the no-cache directive,
i.e., retrieve and render the document again before positioning
you on the capsule link, as should NOT happen.

        Now try Scott's http://www.slcc.edu/index2.html with the
devel code, and active the "[Info]" link to get and display the
document Lynx creates internally for the USEMAP.  The MAP in
index2.html has two AREA tags with just fragments as HREF values,
so in the advanced statusline or showinfo page with the document Lynx
creates for listing the MAP content as links (which is a *different*
document from index2.html the way USEMAP handling is implemented
in Lynx) they're shown as just "#new" and "#display", implying that
if you ACTIVATE them you'll be repositioned within the currently
displayed document, but in fact what will happen is that the
HText stucture for index2.html will be retrieved from cache and
you'll be positioned somewhere in that different document.

        Note also that for some reason you've removed my setting
of the no_cache anchor element when creating the USEMAP list for
display, thereby reviving the bug which Scott reported.  Make a
local copy of index2.html, ACTIVATE the "[Info]" link to create
and display the listing for the MAP content (and thereby cache
its HText structure), then use PREV_DOC to make index2.html the
currently displayed document again.  Now use 'e'dit to modify
your copy of index2.html (in some way that should be visible when
rendered, such as a link name, e.g., change Maps to The Maps).
Now exit the editor, which will cause index2.html to be rendered
again, and in the process cause an update of the MAP content in
the LynxMaps structure.  Now ACTIVATE the "[Info]" link again,
and with the devel code you'll see the stale rendition from cache,
despite the update in the LynxMaps structure.  Because Lynx did
not emulate the Netscape bug, and can encouter and update MAPs
in any document, Lynx should never risk showing a potentially
stale rendition from cache (and it's almost zilch overhead to
create a new rendition from the LynxMaps structure).

        I realize that it would be as much work to remove that
INTERNAL_LINK_ANCHOR stuff as it was to generate and include in
the devel code, but do consider that it really should go. :) :)
 

        Now for the "discretionary" issue of whether to back off,
in part, from what I had implemented based on the Fielding URL
draft.  According to the Fielding survey of current browser behavior
(via: http://www.ics.uci.edu/~fielding/url/), Mozilla/3.0 and MSIE
3.01 still resolve lone fragments versus the BASE, if one was present,
as specified in RFC1808, and not versus the current document's URL,
which represents a change in a draft still under discussion, from
what was specified in the current, actual RFC.  That means that if
you resolve versus the BASE, you can be confident the result will
work for documents whose authors are using those browsers when
generating and "testing" their pages with them.  You can also be
confident that resolving versus the current document's URL will
work with Netscape users' documents, because it's bug ensures that
if it's not above, it's below in the same document (as well as in
the document pointed to by resolving versus the BASE), but that's
not necessarily the case for documents generated by MSIE users.
Current estimates are that MSIE has captured about 30% of the
so-called "market share", and it's usage is still growing rapidly.
The consequence of being wrong when resolving versus the current
document's URL for lone fragments that are positioning instructions
is that the one link will not be accessible to the Lynx users, and
the savings in overhead in the great majority of casess is worth
that risk, IMHO.  The consequence of being wrong when resolving a
fragment which points to a MAP, is that a potentially large number
of links specified via AREA tags in the MAPs content will be
inaccessible to the Lynx user.  Also, when bug reports come in
about such failures and say "It works fine with MSIE.", the
"Why does Lynx do that?" section could be saying that we're
respecting a draft which is still under discussion, and ignoring
the current, actual RFC.  So my personal opinion it that it's
"jumping the gun" not to back off from the Fielding URL draft, at
this time, for that specific case, given that the current Lynx
API doesn't allow looking for the MAP below the IMG or OBJECT
which references it.  But this is just a personal opinion, unlike
the above, which is a matter of bad logic and actual bugs. :) :)
:) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :) :)

        ;( Ugh!  Run-on smileys! );
        
                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]