lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev proposal for LYK_SCRIPT and patch


From: Scott Bigham
Subject: Re: lynx-dev proposal for LYK_SCRIPT and patch
Date: Sun, 4 Jul 1999 00:17:50 -0400 (EDT)

On Sat, 3 Jul 1999, Klaus Weide wrote:

> 1. This is a bad hack based on a bad hack.

This is only tangential to the original subject (and I'm only tangential
to SOURCE_CACHE nowadays...), but I think this merits a reply.

>    SOURCE_CACHE isn't a real cache in the HTTP sense [...]

It's not meant to be.  It piggybacks on the HText cache, and inherits
its expiration and variant logic.  Having duplicates of this logic for
two separate caches seems wasteful, especially since there's little if
any reason for them to differ substantially.

>    [...] and it is incredibly wasteful: it makes a cache copy for each
>    and every URL

Only for documents currently in the HText cache; the cached source is
discarded at the same time that the cached rendering is discarded.  Or
am I misunderstanding your objection?

>    SOURCE_CACHE also messes around with the way Lynx usually does things
>    in weird ways, of which I am still suspicious.

For instance?


As for the proposal under discussion:  I agree that this is probably the
wrong way to produce this functionality.  Your gettidy-esque lynxcgi:/
mechanism looks interesting, though I can't test it with my current
build.  Do relative links get handled correctly?  How does it affect the
cache?

If we really want this done in the code, then just off the top of my
head, I'd say the most straightforward way to do it would be as an
HTStream interposed between the source and rendering, downstream of the
source cache if present.  In a sense, it would be akin to (reloading
and) reparsing the document with inline image links enabled, or with
comment parsing set to minimal.  The filtered source wouldn't actually
live in the cache or on disk anywhere, but would simply be passed to the
rendering mechanism; the cached source (if present) would be unchanged,
and the cached HText would be replaced as though by a reparse.  At that
level, the filtering mechanism shouldn't even care if source caching is
enabled; if it's disabled, then filtering would mean reloading the
document from the `net, but so would changing the comment parsing.

                                                -sbigham


reply via email to

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