Subject: | unbro should not require maximum buffer size |
Date: | Tue, 7 May 2019 08:22:37 -0400 |
To: | bug-IO-Compress-Brotli [...] rt.cpan.org |
From: | tlhackque <tlhackque [...] yahoo.com> |
A block created with $compressed = bro( $data ) can't be uncompressed
with unbro without some a-priori knowledge of the output block size. In
the general case, this isn't available - and is very unPerlish.
Assuming that I trust that the output won't cause unacceptably large
output [memory exhaustion] (e.g. because I put the data into a
database), this constraint is unnecessarily inconvenient.
It turns out that the OO decompressor is more reasonable, as this seems
to be a functional replacement for unbro( $compressed, <unlimited>):
sub debro {
my $bro = IO::Uncompress::Brotli->create;
return $bro->decompress( $_[0] );
}
The XS code for 'decompress' seems to decompress the stream in blocks of
up to about 10MB, appending to a Perl string if the decompressed data
requires more than one such block.
However, this requires the user to create a one-shot object.
Please make the $maximum_decoded_size argument optional. If not present
(or undef), unbro should allocate whatever space is necessary - the XS
version of debro().
This would make bro/unbro drop-in replacements for Compress::Zlib's
compress & uncompress...
If $maximum_decoded_size is present and defined, it's reasonable for it
to act as it does today - die on error.
Thanks.
Also, note that the references to
https://www.ietf.org/id/draft-alakuijala-brotli-08.txt in the POD need
to be updated:
(a) The link doesn't work (and there are several later drafts) - this
does https://tools.ietf.org/html/draft-alakuijala-brotli-08
(b) More importantly, the drafts have been superseded by RFC7932
https://tools.ietf.org/html/rfc7932