[Top][All Lists]

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

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

From: Bela Lubkin
Subject: Re: lynx-dev Why doesn't lynx cache HTML source?
Date: Tue, 10 Nov 1998 20:26:13 -0800

David Combs wrote:

> Not flaming you.  Just the arguments that I keep hearing over
> and over -- make lynx smaller, smaller, smaller.

Size isn't *your* concern, but it is a legitimate concern of some users.
Live with it.

> Certainly there could be options on max bytes to save on disk
> (of course it would be saved to disk, not in core, huh?),

There are excellent reasons why a particular user might choose either.

> and some lru toss-away rule depending on that option,
> and maybe a settable time-limit for cache to stay (with maybe
> optional prompt  "file expired -- want to keep anyway?"),
> etc.
> It would have to be run-time turn-on-offable, so the user could
> determine whether he wanted a simple and at times incorrect
> caching, vs no caching at all.  His choice -- likely made 
> differently at different times.
> I would say that also for this session only, and for only
> this run of lynx -- no second person running lynx could
> use "my" cache.

Again, these are things that might profitably be tunable.  I hadn't
thought about the idea of multiple users sharing one Lynx cache.  An
anonymous site operator might want to do that, to save space while
providing the largest possible cache (== the best user experience).  A
single user on his own system would probably want to save the cache
across sessions.  A sysadmin on a multiuser site where the users *do*
have shell access and can't be trusted with a shared cache, would
probably want each users' cache to be separate and volatile (to avoid
wasting disk space on old, stale cache files for users who haven't even
logged in recently).

Of course, the more tunable parameters we design into it in our heads,
the more difficult the actually programming project becomes...

> Maybe it can be simplified enough (by restricting what it does),
> and optional enough, to be useful to most of us most of the time.

"Simplify" and "make things optional" are diametrically opposed trends...


reply via email to

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