Re: lynx-dev Lynx 2.7.1 and 2.8 refuse to render certain HTML documents

[Bela Lubkin]

David Woolley wrote:

> >                                                                        could
> > you explain again the implications of cacheing?
> 
> - the current code only has provision for caching the rendered version;

Yes, that's the matter under discussion.

> - only power users are likely to make significant use of the source form
>   cache (few mass market users read source, or would understand about broken
>   commenting and quoting styles) - these users are the most likely to be
>   capable of a Unix type component solution;

I disagree.  Several of the rendering controls are things that users
need to be able to toggle, even if they don't know why: comment parsing,
source charset, and DTD.

Once the source cache existed, we could finally add a facility to figure
this stuff out for the user.  I believe this has been mentioned before,
as a pie-in-the-sky future idea.  I think we could almost implement it
now.  Call it a "rendering wizard".  If a document rendered strangely
("hey!  this thing is blank!") the user could hit a "figure out this
document for me" key.  It would come back with something like:

  This document appears to have incorrect comment closure; suggest
  setting "historic" comment parsing.

  This document has out-of-order closure of container tags; suggest
  setting "tagSoup" HTML parsing.

  Implement these settings now [Y/N]? _

or:

  This document appears to require JavaScript.  Lynx cannot render it as
  the author intended.  Please check for a non-JavaScript version of the
  document, or contact the document author for assistance.

> - caching source only has a very real effect on the performance on slow 
>   machines, and caching both has an impact on memory (although you might be
>   able to share the text of contiguous strings between both versions);

???  The performance effects of source caching have everything to do
with the machine's network connectivity; almost nothing to do with the
machine's own speed.  I'm using Lynx at home over a typically 26.4K
modem connection, with no local cache.  The CPU's plenty fast.  Yes, I
know I "could" add a local cache, as you've said many times.  I have a
number of reasons not to do so, and I _will not_.  No number of
assertations that it's easy will change that.

> - disk caching would add to the complexity, especially as you need to 
> implement
>   If-Modified-Since and all the HTTP 1.1 cache control logic to do this 
>   properly;

Lynx already caches pages in memory.  For on-disk cache, I would expect
it to behave exactly the same as it does now, using the disk space as
purely an adjunct to its memory.  In particular, the disk cache would
not persist from one Lynx session to another.  The cache complexity
issues would be exactly as unresolved as they already are in Lynx's
rendered document cache.

> - there are already external caches that will run on the same Unix machine,
>   and in one case would probably be as easy to port to Win32 as Lynx (easier
>   if you've already done Lynx).
> 
> In my view, if you want to provide a package that appears to provide
> sophisticated caching to the end user, the way to do it is is to bundle

I don't want it to provide "sophisticated" caching.  I just want it not
to forget what it has painfully downloaded over a slow connection.  At
least I'm not in Russia any more, downloading over what was effectively
about a 2400 baud connection.

>Bela<