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

[David Woolley]

>                                                                        could
> you explain again the implications of cacheing?

- the current code only has provision for caching the rendered version;
- 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;
- 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);
- 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;
- 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
Lynx with a caching utility, somewhat in the same way that Win32 Lynx
is bundled with a simple sendmail.  If you use the CERN cache, you may
be able to make libWWW a dll (although it wouldn't surprise me if there
are too many Lynxisms in the current Lynx version).  With a suitable
installer, the whole lot can seem like a single application, like the
many DLLs and exes that make up MSIE/Outlook are treated as a single
package by the users.

If you want to make a concession in the Lynx code, it should probably
be to include Unix domain socket/DDE/OLE support for talking to a cache,
to avoid any issues to do with grabbing TCP port numbers.