Re: lynx-dev Re: lynx timeline

[Bela Lubkin]

Ilya Zakharevich wrote:

> One can deal with any scheme the following way: when the first byte of
> *content* (as opposed to headers/envelop) is recieved, the old version
> is purged.  So if no headers are defined for a scheme, the purge
> should happen on the first successful read()/recv().

But that is _another_ user preference item.  I would rather purge the
old when the new has been _fully_ received -- at the moment when the
underlying protocol says it's done.  Suppose I'm reading a long document
when I suddenly decide to reload it (maybe I suspect the owner is
updating it periodically).  The reload starts, but then stalls (an
intermediate router goes down).  I would like to be able to abort the
reload and revert to the previous, entire version of the document.

Actually, I'd like to be able to do that even if the reload completed
entirely successfully.  I'd like to be able to compare the old and new
versions, see what the owner changed.

These ideas imply some extensions to Lynx's internal knowledge about a
document.  It should know whether the document is complete or partial.
It should have a sense of temporal ordering; that is, if it has multiple
complete versions of the same document, it should know which is the
"newest" according to reload order, and display that one by default.
But it should also have a way for the user to request (by some new menu
or set of hotkeys) to view any other versions of the document that are
in cache -- older versions, partial versions, whatever.

The "temporal ordering" _could_ be by document timestamps as received
from the server; I prefer that it be according to local receipt time.
That is, suppose we loaded the document twice, and the second one
received had an older timestamp according to the server.  (This could
happen if someone was moving files around on the server, or if the
"server" was actually several servers being exposed round-robin fashion,
and they were out of sync.)  I would want the most recently _received_
version to be shown as "current", not the one with the newest server
timestamp.  But this is probably yet another user preference setting...

Keeping track of multiple versions in memory (or in cache, wherever we
happen to be storing that) is something that ought to be done anyway.
For instance, Lynx does a reload if you change your preferred languages;
it does a new HTTP request giving the new list of languages.  Now if you
change back to the original language, it does yet another reload,
instead of using what it could have kept in its cache.  You might object
that the space of things that you might change locally, forcing a
reload, is so large that there's no point in caching specific points
because you'll never revisit them.  But this is only true if you think
the trajectory in this space is _random_.  In practice, if you change
language from "A" to "B", just about _the_ most likely thing to do next
is change language from "B" back to "A".  Likewise with document
character set, and anything else you might change that would lead to a
reload.

I'm not going to implement this stuff myself, and I'm not "demanding"
that it be done, just wishing...

I will offer the opinion that, if someone were to do this major
restructuring of the cache, it would not be appropriate for 2.8.5, but
should be held to 2.8.6 or 2.9 or whatever comes next.

>Bela<

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden