camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Grobmeier <>
Subject Re: Zip format problem
Date Mon, 05 Oct 2009 05:04:01 GMT
> I'm not sure now whether I should try creating the patch as I planned,
> because what Christian suggests (extracting camel-compress) is obviously
> better and superior solution. If he wishes to do it, I'll be happy to
> contribute whatever I can.

Of course, jump in and enjoy. However, plase think on backwards
compatiblity - I am pretty sure people would like to see you solution,
even when it gets deprecated once the compress component is available.

Claus (or others): what is the policy with existing apache committers?
Is there a chance that I can get karma to the sandbox? I would like to
avoid developing this on GIT with Vlaidimir and then have it back
through the incubator.

> It is also an interesting point the other Christian raised - about an
> archives containing many files. It would be great to support tar.gz/tar.bz2
> archives as well. In fact, this is not even specific to compression - I
> would say that a generic data format concept should support
> spitting/aggregation - consider MIME emails with attachments for example.
> I'm not that much in EAP background and camel internal design (yet?) to
> suggest how that aspect might be implemented however.

Yes I also think thats interesting. Lets consider this when we dig
deeper into camel


> Claus Ibsen-2 wrote:
>> But it may be a bit weird doing
>> .unmarshal().compress() to do de-compressing :)
>> So maybe .compression() is a better name for it?
>> But is that much different that .unmarshal().zip() as it will also
>> de-compress using zip.
>> For now I like option #3 the best.
>> --
>> Claus Ibsen
>> Apache Camel Committer
>> Open Source Integration:
>> Blog:
>> Twitter:
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

View raw message