lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Klaus Weide
Subject: Re: lynx-dev dev22 - patch to fix PSRC mode with SOURCE_CACHE!=NONE
Date: Wed, 21 Apr 1999 07:15:54 -0500 (CDT)

On Mon, 19 Apr 1999, Scott Bigham wrote:

> On Mon, 19 Apr 1999, Klaus Weide wrote:
> 
> > 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().
> 
> Well, the problem there is that the only place I could find where I
> could get at the actual incoming data was about five layers below
> HTLoadDocument(), at the HTStream level.

Well, I think you have handled the receiving-data part elegantly.
It could be more general, by not being in HTML.c but in a separate
file (yeah, it's probably a pain to add a new source file to all the
relevant makefiles & scripts).  The newer libwww has a generic T-piece
HTStream for this kind of thing (HTTee()), like UNIX tee.

I don't like though that the source_cache_chunk and source_cache_file
are passed around as global variables; they should probably be structure
members (maybe indirectly) of the HTParentAnchor.  {If you have already
discussed this, my apologies, I haven't read all the messages about
this fast-changing area.}

> Up at the getfile() level,
> AFAICT, you just stick a document address in one end and get an HText
> out the other.

Well you get one or don't get one.

> Now, I suppose if getfile() could be taught to check for
> a cached source, it could call HTreparse_document() at that level
> instead of HTLoadDocument(); but I'm still putting my brain back
> together from my last attempt to decipher getfile(), :-} so I doubt I'll
> be able to pull that one off.

You have managed to decipher the HTStream stuff, so getfile() shouldn't
be a big problem for you. :)

Maybe with Leonid's new code this will be irrelevant, if he comes up with
a cleaner mainloop()...

   Klaus


reply via email to

[Prev in Thread] Current Thread [Next in Thread]