Hi I have a patch waiting to be committed to commons-imaging which uses the LZW stuff in commons-compress (brief mention of it by me on IMAGING-126), so it could break with these changes. My hope was to wait for the next release of compress before committing, so I could use that version of compress as a dependency.
Also, LZW is a very loose algorithm with many important differences between implementations in ZIP, Z, TIFF, GIF, etc. It is difficult to generalize. I was even somewhat against the idea of making a general LZWInputStream, as opposed to a customized LZW decompressor in every place where it's needed. Just changing things in the class because of how it seems to be used in compress, will definitely make more general use difficult/impossible. IIRC, some code in imaging already did need to set variables which no code in compress does. Damjan On Sun, Feb 1, 2015 at 4:17 PM, Benedikt Ritter <benerit...@gmail.com> wrote: > > > Send from my mobile device > >> Am 01.02.2015 um 07:04 schrieb Stefan Bodewig <bode...@apache.org>: >> >> Hi >> >> I'm trying to bring together two separate discussions from two different >> [VOTE]-threads. It seems as if I should cancel the RC2 vote and before >> I rush another RC maybe we can get consensus on what to do. >> >> * my experiments show that moving the LZWInputStream class hasn't got as >> big an impact on subclasses of ZCompressorInputStream as I and others >> would have expected. This likely means we can relax the warning of >> the release notes and site again. Right? Is anybody going to perform >> more experiments? > > I think we're safe to asume that the change will not break clients. > >> >> * (Internal)LZWInputStream has a bunch of protected fields that slipped >> through a few releases ago. We should add getter/setter pairs and >> deprecate using the fields. Sebb would like to even make the fields >> private assuming the chance of people actually subclassing >> ZCompressorInputStream and using said fields is very small. > > Even creating getters and setters and deprecating the fields is the way to go > here, IMHO. > >> >> Any opinions? >> >> Stefan >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
