On Sun, Oct 4, 2009 at 12:45 PM, Christian Grobmeier <[email protected]> wrote: >> Camel provides a pluggable data format so we can have implementations >> outside the camel-core >> >> But a selected few do not depend on 3rd party .jars which of course >> allow us to host the implementations directly in camel-core. > >> Cool if you want to help then please take a look and see what you >> think needs to be done. > > I just looked at it. Following your explaination with dependencies and > looking at c-cores pom, I think that the ZipDataFormat needs to be > extracted as a plugable implementation. > > If one would do this, we could do this also for GZipDataFormat which > also is cared of by Compress. > > Same goes with ar, cpio, tar and bzip2 which could mean that the > camel-compress component could support various additional formats > which are not supported at the moment (or so it seems to me).
I like the idea of a single camel-compress component which offers a range of compression libraries. It would be too fine grained having a single component for: tar, zip, rar, bzip2 and whatnot exists. Does Apache Commons supports a uniform API for these underlying compression libraries? > > The ZipDataFormat and the GZipDataFormat looks quite forward to me. I > think with compress it's the same amount of source lines. > Yeah I doubt there is too much code needed to bridge Camel with these compression libraries. > To guarantee backwards compatibility the current Zip-Impl should be > deprecated but enhanced with Vladimirs suggestions. > Yeah if we could make a new camel-compression component that host all the new data formats for compression. Then we can @deprecate or what makes the most sense the old data formats. I gotta take a closer look at his suggestion. > Wdyt? > > Cheers > Christian > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
