Re: [rfc] hide rs_buffers_t from public interface

--rJwd6BRFiFCcLxzm
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

(Trying to convince myself perhaps.)

The one case where rs_buffers_t is the simplest interface is where the
application has all the input data already in a buffer in memory.
Perhaps it has been mmaped from a file or perhaps it was produced by
some other routine. =20

This case ought to be pretty simple: allocate a big output buffer, set
up a rs_buffers_t and just make one call.

This is probably not a very good design for most applications, because
it limits the amount of data they can process to the largest buffer
they can allocate.  It is very common today to have x86 machines which
can only allocate contiguous chunks of 1GB or so, but that have disks
of 100s of GB.  It is pretty common to have single files larger than
can be held in memory.

Perhaps some kind of embedded application that needs to decompress
something from ROM/flash?

Even here, output is a problem.  The application needs to either have
a maximum-sized buffer, or do dynamic allocation.  Dynamic allocation
and resizing the buffer might be as easy to do through a callback
rather than buffer structures.

--=20
Martin=20

--rJwd6BRFiFCcLxzm
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAMrfVPGPKP6Cz6IsRAn0JAKCQDn8eZh5OPufaveDya4/sGfIrQwCgxDs5
zm3pu9/KU5RntTFpmJ4OjBc=
=LOZp
-----END PGP SIGNATURE-----

--rJwd6BRFiFCcLxzm--


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click