lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev internal cache proposal


From: Klaus Weide
Subject: Re: lynx-dev internal cache proposal
Date: Tue, 17 Nov 1998 15:16:03 -0600 (CST)

Lots of questions here:

On Mon, 16 Nov 1998, Leonid Pauzner wrote:

> Lynx internal cache implementation proposal.
> 
>     - the source of every document now cached for greatly speed operations
>       which require a re-parse, including '\' view-source,
>       '^V' other-DTD, '*' image-URLs, '[' pseudo-alts,
>       '"' soft-dquotes, '`' and "'" comment-parsing,
>       '@' raw-mode, and changes in assumed document character set.
>       This also work for downloading document from the History page
>       and would probably usefull for future table implementation (if happend).

What do you mean with "internal" cache?  (Everything implemented in lynx
is internal to Lynx :) )  So we already have one internal cache....

You don't really say anywhere whether you want to cache on dosk ore in
memory.  (I assume in memory.)

>     - simple HTTP 1.1 cache implemented, e.g. if you request http:// document
>       for purposes other than listed above, the document's source
>       already in lynx internal cache and the requested method is GET -
>       a "conditional GET" request follows (one include additional headers
>       If-Modified_Since and/or If-None-Match against cached value 
> Last-Modified
>       and ETag). If the remote server (or proxy) detect no change and returns
>       with 304 (Not Modified) status - our internally cached entry used.

How does this interact with the current cache?  Is it always flushed when
your cache kicks in?

Anyway, is this second paragraph necessary for implementing what's in the
first?  Or is it just an added bonus?

>       Proccessing the other statuses have not been changed.

Does it invalidate the cache?  Does the cached copy get deleted?

>       The header of cached entry updated with every responce.

Hmmmm.  Where do you keep the headers?

>       We also change lynx request header from "HTTP/1.0" to "HTTP/1.1"
>       to allow server send us ETag for best caching validation

Bad idea, as explained in another message.

>       (does we lost something that SHOULD be implemented in HTTP 1.1 client?).

Yes.

>       The expiration status calculated by LYinternal_cache_stale() function.

Suggestion: see is_fresh() (or similar name) in HTCache.c of newer libwww.
Suggestion: Keep dates as time_t values, not strings. (or: in addition.
keep sting value for display in '=' screen.)

>       The documents we sure as not expired will be loaded from internal cache
>       immediately (no DNS search, no HTTP request).

What happens with ^R?  'x'?

>       No methods other than GET http:// cached (except for internal use like 
> ^V).

Do we HAVE TO discriminate against FTP?

Anything to do about HEAD?

>       It should be stressed separately that according to HTTP 1.1 and 1.0,
>       the expired or "no-cache" document may also be cached but
>       the conditional GET request SHOULD be proccessed for validation
>       by the remote server, not an intermediate proxy nor ourself
>       (so "no-cache" directive act on validation, but data may be valid).

What section are you referring to?

Why is this significant here?

>     - Implementation details: cache updated in LYAddVisitedLink(),
>       e.g. when the document already received successfully,
>       there should not be any problem from redirections.

What does "cache updating" mean?
I mean, you already have the data, so you already have updated the cache,
right?  Or do you temporarily want to have two full copies?

>       Klaus's internal (#fragment) links now obsolete and will be removed 
> soon.

What has it to do with your cache?

It is not obsolete IMHO.

>     - Possible problems/future domain:
>       LYinternal_cache_stale() currently assume any document expired for sure,
>       will be fixed soon. 

Does that function already exist?

>       Method POST may be not cached for internal use
>       like changing ^V etc. 

Why not?

>       SSL? Redirections?
>       Cache recycling mechanism?

Too brief to understand what you mean.

>       Persistent cache can be implemented easily when everything else done.

Maybe.

>     - Questions:
>       * If we interrupt transfer with 'Z' - the result will be cached
>       for "internal use" but assumed as already expired for normal 
> operations(?).

Define "for internal use" please.  If you mean ^V, '*', '[', .., maybe we
can find a better term.  Anyway, in that case your idea probalby makes
sense.

But a safer way would be to discard incomplete stuff.

>       Probably it should not be forced as expired but not persistent for sure.
>       * Should any responces besides 200 (OK) status be cached?
>       * #fragments?

Shouldn't have anything to do with it.

>       * compressed files?

Why not? :)


   Klaus

reply via email to

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