lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev Why doesn't lynx cache HTML source?


From: Klaus Weide
Subject: Re: lynx-dev Why doesn't lynx cache HTML source?
Date: Thu, 19 Nov 1998 11:33:11 -0600 (CST)

On Wed, 18 Nov 1998, Leonid Pauzner wrote:

> 
> That is exactly what I mean in another words (much clear here).
> but see near the bottom.
> 
> 18-Nov-98 08:14 Klaus Weide wrote:
> >      complete                                                 use all
> >      semantic   <----------------------------------|-------> cached data
> >    transparency                                    |          forever
> >                                             Lynx in general
> 
>  [...]
> > There are several "modes" of going to a page:
> >  1) explicit reload: ^R, 'x'
> >  2) '*', '\', '[', '"', ^V, etc.
> >  3) form submissions (POST)
> >  4) following a normal link, entering an address with 'g' etc.; default
> >  5) going back in history: either left arrow, or link from History Page
> [...] 
> 
> > If the new rawbyte cache never gets used for requests other than mode 2,
> > then no change is needed in the rules for when to make a new request,
> > and no If-Modified-Since/Etag implementation is needed to preserve the
> > current behavior.  IMS/Etag/304 could still be implemented later, but
> > that is then a separate problem.  (It could also already be implemented
> > already now, for the existing rendered-doc cache, [except for the
> > "language confusion" problem,] which shows that it is separate.)
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^??

I meant the confusing flags the mainloop() and others (for example in 
LYHistory.c) use to communicate their requirements w.r.t. caching to
the lower-lever functions.

> > But it DOES seem wasteful to keep raw data if in most cases we won't
> > use them.  But:
> >   B. It can be greatly restricted what documents get entered into the
> >      cache in the first place.  We have a choice of
> >      - Caching everything received.
> >      - Caching all text/html, maybe with further restrictions based
> >        on URL, method, etc.
>  also restrictions on file://localhost which always available
> >      - Require explicit user action.  Maybe a special "Enter cache" key,
> >        meaning "I am going to want this text reparsed, so start caching
> >        it".
>  ???
> >      - When '\' is pressed the first time for the current text, we mark
> >        if for rawbyte caching.  There could be a confirmation question.
> >        That means at least two network request are needed, but after that
> >        cached data is used.
>  ???

I am not sure what your question is.  Can you explain?

 [ ...]
> But I think "mode 2" need no confirmation in any case:
> every text/plain _rendered_ document should be cached in rawdata
> if it currently cached in rendered form, otherwise fall back
> to the present behaviour (no rawdata cacheing at all).

Maybe.  But I may not want that if the document is big (even if
I want it for some documents).

> Of cause, rawdata cache may be larger than rendered cache.

Do you mean more documents, or do you mean more bytes for each document?


    Klaus

reply via email to

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