Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Kafka, mail # dev - Re: [jira] [Updated] (KAFKA-187) Add Snappy Compression as a Codec and refactor CompressionUtil and option on startup to select what the default codec


Copy link to this message
-
Re: [jira] [Updated] (KAFKA-187) Add Snappy Compression as a Codec and refactor CompressionUtil and option on startup to select what the default codec
Jeffrey Damick 2011-11-12, 19:24
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
<[EMAIL PROTECTED]>wrote:

> 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
> maybe
> > 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).
>