> 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 Cheers > > 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: http://fusesource.com >> Blog: http://davsclaus.blogspot.com/ >> Twitter: http://twitter.com/davsclaus >> >> > > -- > View this message in context: > http://www.nabble.com/Zip-format-problem-tp25723682p25737304.html > Sent from the Camel - Users mailing list archive at Nabble.com. > >
