From: Konovalov, Vadim [mailto:[EMAIL PROTECTED]
> > I've just been through the should-I-shouldn't-I-support-5.4 with my
> > (painfully slow) rewrite of Compress::Zlib. In the end I
>
> ...
>
> I always thought that Compress::Zlib is just a wrapper around zlib which
> in
> turn is C and developed elsewhere (and in stable state for a long time
> now).
Yes, that is mostly true, but there have been a few changes made to zlib of
late that I want to make available in my module (the ability to append to
existing gzip/deflate streams being one). Plus I had a list of new
features/enhancements I wanted to add that have been sitting on a TODO list
for ages.
The top issue in my mailbox for Compress::Zlib is the portability of the
zlib gzopen/read/write interface. I've now completely removed all
dependencies on the zlib gzopen code and written the equivalent of that
interface in Perl. A side-effect of that decision is that I now have
complete read/write access to the gzip headers fields.
Another reason is provide better support for HTTP content encoding. I can
now autodetect and uncompress any of the three zlib-related compression
formats used in HTTP content-encoding, i.e. RFC1950/1/2
etc, etc...
> What is "(painfully slow) rewrite"?
I don't have as much time to dabble these days, so I've been working at it
on and (mostly) off for at least a year.
Whilst I'm here, when I do get around to posting a beta on CPAN, I'd prefer
it doesn't get used in anger until it has bedded-in. If I give the module a
version number like 2.000_00, will the CPAN shell ignore it?
Paul
___________________________________________________________
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
