lynx-dev
[Top][All Lists]
Advanced

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

Re: lynx-dev [BUGS 2.8.3.dev4] partial, off-by-one


From: Chuck Martin
Subject: Re: lynx-dev [BUGS 2.8.3.dev4] partial, off-by-one
Date: Wed, 21 Jul 1999 11:34:38 -0400

On Wed, Jul 21, 1999 at 07:43:42AM -0500, Klaus Weide wrote:
> 
> On Tue, 20 Jul 1999, Leonid Pauzner wrote:
> > > On Sun, 18 Jul 1999, Leonid Pauzner wrote:
> > 
> > >> >      * From: Ilya Zakharevich <address@hidden>
> > >> >      * Date: Sun, 18 Jul 1999 01:24:58 -0400 (EDT)
> > >>
> > >> > a) I could not understand whether "partial" should work with local
> > >> >    gzipped files.  As far as I can see, it does not work.
> > >>
> > >> It should (according to the code) work if lynx compiled with zlib, 
> > >> otherwise
> > >> it doesn't (lynx will call gzip to decompress the file first and then 
> > >> load
> > >> temp file in a standart way, using "partial" mode if enabled, isn't it?).
> > 
> > > Are you saying it should *not* work if lynx is not compiled with zlib?
> > Yes, it was my wild guess (based on loading remote gziped files).
> > After decompression lynx will load uncompressed temp file but that will be
> > the next stage, right?
> 
> Yes, but shouldn't it "work" during that "next stage"?  (I am not sure
> whether it does.)

I think what Leonid was saying is that if lynx is compiled with zlib, it
can unzip the file as it arrives, and therefore partial display would
work just like with an uncompressed file.  Otherwise, the whole file has
to be downloaded first, and then gzip called to unzip it in its entirety,
and only then can it be rendered, with partial display working during
the final rendering stage, and not during the downloading or unzipping
stages.  The effect would be a much longer wait than if lynx was compiled
with zlib.

I'm not sure if that's correct, but I believe that's what Leonid meant,
and on the surface it makes sense.

Chuck


reply via email to

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