-Re: [jira] [Updated] (KAFKA-187) Add Snappy Compression as a Codec and refactor CompressionUtil and option on startup to select what the default codec
RIght, but on the other hand if every compression under the sun is allowed,
then you could end up with a very fractured client community of support.
I guess I'd like to see a client RFC of sorts, but maybe I'm the only one
that cares about alternative language support... :)
On Fri, Nov 11, 2011 at 2:22 PM, Chris Burroughs
> On 11/11/2011 01:55 PM, Jeffrey Damick wrote:
> > So with regard to the
> > KAFKA-187<https://issues.apache.org/jira/browse/KAFKA-187> what
> > is the stance going to be on supporting new compression methods? Is it
> > expected that all clients 'must' & will support them? If not, is there a
> > set of 'required' compression codecs? Jun mentioned not wanting every
> > language to re-implement a thick client, but where is the line between
> > thick and thin? It seems like there needs be a clear set of expectations
> > for what a client implements, regardless of language or platform, or
> > I'm off in the weeds..
> I think realistically if we try to say that we can only include
> compression codecs that every client language supports our only codec
> will be gzip (or maybe bzip2, but that's ill suited for most uses cases).