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 [EMAIL PROTECTED]
