Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE

[Leonid Pauzner]

19-Apr-99 10:45 Klaus Weide wrote:
> On Wed, 14 Apr 1999, Scott Bigham wrote:
>> On Wed, 14 Apr 1999, Leonid Pauzner wrote:
> [ .... ]
>> > More problems expected since we now reload documents
>> > out of mainloop() cyrcle.
>>
>> Not so much outside of mainloop(); we're just tripping over things that
>> would normally get cleaned up behind getfile().  And yes, I do expect to
>> run into more of them... :-(

> Uhmm.  I've been following this only from the sidelines, but it reminds
> me of the discussions we had last November (see messages containing "cach"
> in the 1198 archive, including my long blurbs
>   <http://www.flora.org/lynx-dev/html/month1198/msg00428.html>
>   <http://www.flora.org/lynx-dev/html/month1198/msg00457.html>).
> It seems the source caching is implemeted in a way I woudl have preferred
> to avoid: data flow separate from the normal getfile() chain, a new
> and very different way to determine freshness, and overall control

Yes, it was implemented in a way you were preferred to avoid.
But this may have a good sides also: current mainloop/getfile stuff
already-too-big and hardly maintainable.
Now, when source_cache implemented by someone else I have fixed most
mainloop problems in an elegant any clear way (submitted to Tom privately,
will be available in dev23 soon). This actually *simpify* mainloop
since we got a chance to look there from the other point of view
(correct display partial logic in particular). In the other case
we would fall into all kind of warnings with the replay from POST resubmit
etc. Current caching mechanism hardly maintainable either.

I have not figured out yet how we can implement http caching
we discussed in November, but probably it is possible rather easy.
We may try an equivalent of HText_select() somehow and go that way,
probably just put HTreparse_document() in HText_select()
with the appropriate checks. Isn't it?


> concentrated in already-too-big mainloop().   The result is numerous
> tweaks for cases that were not considered at first, with more to come.

> Don't get me wrong, it's great that you have done something while I was
> only talking.  Still, if there is a way you can reconsider the place
> where this is basically controlled, to move it away from mainloop()
> tweaks, please do it...

> If the gimme-data part were sitting somewhere between getfile() and
> (current) HTLoadDocument, we'd get the benefits of all the various
> checks that are (especially) in getfile().  Granted, they seem not
> to be needed now, since we're only reloading a document that has
> been loaded and so must have already been checked.  But relying on
> this makes it much more difficult to expand the reach of the source
> cache later (should we want to use caching for not-already-loaded
> documents), or to handle properly the case where the checks done
> in getfile() depend on settings that can change at runtime (and
> I understand that may be the case now, with the edit-lynx.cfg
> changes).  Basically, part or most of getfile() [and others?]
> would have to be duplicated.

>    Klaus