[links-list] Re: gzipped files - final

Petr Baudis pasky at pasky.ji.cz
Wed May 1 10:53:24 PDT 2002


Dear diary, on Wed, May 01, 2002 at 01:02:41PM CEST, I got a letter,
where Witold Filipczyk <juandon at poczta.onet.pl> told me, that...
> On Fri, Apr 26, 2002 at 06:13:32PM +0200, Petr Baudis wrote:
> > Dear diary, on Sat, Apr 20, 2002 at 09:44:04AM CEST, I got a letter,
> > where Witold Filipczyk <juandon at poczta.onet.pl> told me, that...
> > > I am proud of this patch.
> > > I hope it will be applied.
> > > lua hook for .gz files isn't necessary.
> > 
> > ..quoting myself..
> > 
> > It's needed to move all this functions to some special file and build some kind
> > of abstraction upon it. I'd imagine it as:
> > 
> > struct z_stream *z_open(int fd, int z_type);
> > int z_read(struct z_stream *, ...);
> > void z_close(struct z_stream *);
> 
> Too much effort.
> 
> Compressed local files and compressed http it will be easier and clearer
> to handle independently (without additional "meta-library").
> I know it is difficult to understand what I mean.
> In attachment there is an example.

See below. The code duplication may rise dramatically with adding of the new
encodings, and I just want to be able to add it on one place and feel safe.

> Now gzipped files support is clearer.
> Maybe bufsize_for_gzip should be increased (8192 will be better ?)
> I don't know how to get size of decompressed file before decompression.
> There is no need to test if file is gzipped or not because zlib
> handle both.

Yes, the new patch looks much better! :)

> > It'd be nice to have proper header on the top :). You know, I feel that keeping
> > code in uniform and clean state is very important.
> > 
> > > +AC_ARG_WITH(zlib, [  --without-zlib          disable zlib support],
> > > +	[if test "$withval" = no; then disable_zlib=yes; fi])
> > > +if test -z "$disable_zlib"; then
> > > +	AC_CHECK_LIB(z, gzdopen)
> > > +	AC_CHECK_HEADERS(zlib.h)
> > > +fi
> 
> I don't really know how it should be.
> In today's version zlib is not enabled by default and configure.in surely
> needs some tuning.

Hmm, why it's not enabled by default?

> > This is something similiar. Well, no sense to comment on this, as we're going
> > to move this away anyway, aren't we?
> 
> I don't think so.
> Now support for gzip files is clear (only in file.c).

And when we're going to add support for another encodings? From bzip2 to
crypted files? ;)

I just want to do things properly, when we're already doing them. Otherwise
only mess and code duplication will arise in the future..

> When I first look at read_http_data light despodency come over me,
> but it shouldn't be so difficult to add gzip support, although many
> -2 , 2 and other numeric values in this function.

Uh..oh? :)

> I'll go in for it now to celebrate today's "prazdnik".

Good idea :).

-- 
 
				Petr "Pasky" Baudis
 
* ELinks maintainer                * IPv6 guy (XS26 co-coordinator)
* IRCnet operator                  * FreeCiv AI hacker
.
Object orientation is in the mind, not in the compiler. -- Alan Cox
.
Public PGP key && geekcode && homepage: http://pasky.ji.cz/~pasky/
-- 
Unsubscribe: send email to links-list-request at linuxfromscratch.org
and put unsubscribe in the subject header of the message



More information about the links-list mailing list