Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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).
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB