LYNX-DEV Re: memory cache things (was: hidden links mods)

[Klaus Weide]

Fote,

 Let's wait whether the folks on the URI list have something to say about
it, okay?  I am not avoiding the issues here, but feel I have said what
I have to say and could only repeat it in some other formulation.  Well
if you feel I didn't answer you questions, or was too brief, let me know,
then I'll try again.

Now to some of the related, but different topics:

>       You offered the test in:
> 
>       http://www-1.openmarket.com/browsertest/cache/nph-linkpagecache.cgi
> 
> as an example of the devel code now doing cache regulation correctly.
> However, as it's cover page states:
> 
> 
>     According to the HTTP 1.0 Specification, browsers and proxies must not
>    cache Web pages whose Expires header is less than or equal to the
>                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    returned Date header. This test consists of returning a "non-cachable"
>    ^^^^^^^^^^^^^^^^^^^^
>    page to your browser and determining whether your browser caches it.
> 
> Neither the devel code, nor the vanilla code, nor the fotemods code at
> that point, had anything in it to compare Expires versus Date headers
> for making the document "non-cachable" (treating the comparison as
> equivalent to a no-cache directive).  

Right - it "worked" because the clock on sol is a few minutes ahead of the
clock on the Openmarket server...  so that an Expires header set to the
current time at that server would always appear "in the past" on sol.
Lynx would take that to mean "set the no-cache flag".  You have changed
the comparison to a more valid one (at least for HTTP headers), so that
the result would not depend on such arbitrary things as system clock 
difference.

I didn't look closely at why "no-cache" was being set, just noticed that
it was set (and consistently - since that time difference didn't vary
too much).  I was looking at the difference in handling given that 
"no-cache" *was* set - for whatever insufficient reason.
As you note yourself:
>                                       However, this still has nothing
> directly to do with whether no-cache directives should be ignored or
> not with respect to fragment instructions.

[...]
>       The rules for cache regulation are in the HTTP RFCs, not the
> Fielding draft. [...] 

I note that the HTTP RFCs don't talk about HTML META tags.

>                       I've been adding cache regulation based on header
> or META directives, but it is still far from complete.  My concern is
> that your mods brake the logic of that regulation, creating bugs that
> will have long term consequences for further development of cache
> regulation in Lynx.

This sounds like you are having a long-term plan.  May I ask what it is?
 
>       The logic in the vanilla code and fotemods (though the code
> itself has had bugs, and might still have bugs in the fotemods) is
> based on the distinction between "cache" and "history", [ .... ]
 [ ... long paragraph explaining cache/history distinction ... ]
 [ ... ending with: ] 
> mods in the devel code which [...] will have long term, adverse
> consequenses for any further devolpment of cache regulation according
> to the HTTP/1.1 RFC.

And this too sounds like you know what that "further development of
cache regulation" will be.

Hmm.  Can we stop here for a moment, and ask whether cache regulation
according to HTTP/1.1 is actually A Good Thing, and why?

So far, changes in cache regulation most of the time meant adding more
conditions under which the no-cache flag is set.  Now whenever I see
a new HTextSetNoCache() call appear, I dislike it.  I am speaking for
the user with a 14400 modem here, because I AM that user.  Adding more
cases where Lynx automatically reloads a page - and I can do nothing
to prevent it - is not what I like.  There has to bee an OFF switch
somewhere for this.

This is of course all done for the ideal of "semantic transparency".
Well I personally don't care much about semantic transparency if that
means more and more reloads for frivolous reasons, or just so that
a content provider can push a different one-line "ad banner" on my
screen as often as possible.  I already know where my ^Refresh key is,
thank you very much.

Now where are all those useful services that *require* semantic 
transparency - I don't see many of them, instead I see all those weird
META tags and so on popping up which essentially say "Here! I Am Important!
Reload Me Every Second!".

Ok, enough of this rant style.  But I seriously think that it is not
automatically good to implement as much as possible of HTTP caching rules
in Lynx - at least not without making it configurable.  Otherwise we lose
some of the speed advantage of Lynx.  Taking those HTTP rules really
serious would probably mean applying most of the rules proxy caches have,
including to never cache a page which doesn't have a Last-Modified
(or other freshness-regulating) header - and there are lots of those.
All this is also more problematic with Lynx because there is no way
to go "forward in history" - I cannot revisit that page, which I just left
with PREV_DOC, without reloading it, if it happens to be marked no-cache.

And I really hope you do not want to implement more cache regulation
using just this one no-cache flag and the existing LY* global variables.

[ As for my mods breaking anything about this - show me where.
  It's easy enough to turn the whole thing off, just change one #define
  in HTML.c.  That should give exactly the previous behavior - modulo
  bugs that likely are there (and I mean real bugs, not "I disagree"
  "bugs").  Then add a bit of HText_areDifferent() in some places, and it
  should behave like fotemods. ]

      Klaus



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