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

[Leonid Pauzner]

21-Apr-99 06:41 Klaus Weide wrote:
> On Mon, 19 Apr 1999, Leonid Pauzner wrote:
>>
>> 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.

> Well that's true, at least as far as mainloop() goes.
> I don't find getfile() that bad.  It's basically a filter on the request
> to
> - ckeck various kinds of permissions,
> - shortcut some requests (don't go through HTLoad*),
> and
> - the redirection loop.
> The function is too big and should probably be split, but at least
> it's not completely unclear how to split it up...

I mean that changing layout parameters like '[' or '*' should not affect
any getfile items listed above - all permissions already checked
and we just do operations for _already_loaded_document.

> (OTOH some of the checks that are in mainloop() should probably be
> moved to getfile() [or its successors] )

>> 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).

> I'd prefer if you had sent it to the list, too...
I already sent in (sorry, it was work in progress so I sent several patches
one over the previous so it was not clear. I thought Tom check in dev23
on Monday. Well, will send a final form now).

>> 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.

> Can't comment on the magic bullet since I haven't seen it.

>> Current caching mechanism hardly maintainable either.

> ?? Please elaborate.
I ment LY_force_no_cache, LYoverride_no_cache, HText_stale()...

>> I have not figured out yet how we can implement http caching
>> we discussed in November, but probably it is possible rather easy.

> You probably mean "304 not modified"?  (Not quite the same as
> http caching itself)

>> 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?

> That might work; problem is, what are the appropriate checks?
I think no problem to find an answer to that question.
The bigger question is to split HText and HTParentAnchor
so we could get a number of cached sources more then HText's -
this is rather important for our needs.

>    Klaus