Hi, Guillem Jover wrote: > On Sat, 2009-10-24 at 17:41:02 -0500, Jonathan Nieder wrote:
>> This patch refactors the callers for zlib and libbz2 library >> functions to share some code, in preparation for some small >> changes that apply to both. > > This one I didn't apply, as the code just seems similar, but it would > make it more difficult to handle once the need to diverge. Looking at the resulting compress.c, I agree... > Also given > the signal handling brokeness and possible refactoring and combination > with the buffer API I might want to rewrite those w/o using the > compression library IO interfaces. ... especially considering that something generic like this ought to happen anyway. As long as these are being hooked into the buffer API, using the lower-level deflate()/inflate()-style interfaces for now does seem like the right thing to do. I am imagining a new BUFFER_WRITE_COMPRESSED where the associated data is a pointer to a struct with a pointer to a compressor and whatever state the compressor needs. Do you think the lower-level deflate()/inflate() interface is the right one to use? If it is not hard to do, I think it would be better to teach zlib and libbz2 to behave better. Whichever way we go now, it is easy to switch later. I’ve filed the zlib bug as <http://bugs.debian.org/568149>. Thanks for reporting the libbz2 suggestions before, by the way. Regards, Jonathan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
