We could of course also have a spearate module for gzip.
The reason why I think about moving it to core is that it just contains
3 classes and does not have additional dependencies.
Basically I like the idea to separate modules on the architecture level.
On the runtime level I doubt though that any user would mind having
these classes
available every time.
About a prefix for the gzip classes. I also thought about what could be
suitable. Of course gzip is kind of on the transport level but it is no
transport. So perhaps it is a kind of a transformation or encoding.
Christian
Am 30.01.2012 11:43, schrieb Sergey Beryozkin:
Hi Christian
On 30/01/12 10:34, Christian Schneider wrote:
We currently have a transports/common project that only contains the
gzip feature.
As this feature is even used from core I propose we move it there and
remove the whole transports/common module.
As far as I recall the gzip feature was in transports/http originally
and then there was a demand for GZIP be supported at the JMS level...
I proposed to move it to transports/common as opposed to rt/core, it
does not seem to belong to the core really, as it's a very transport
specific feature
I would like to change the package name from
org.apache.cxf.transport.common.gzip to org.apache.cxf.gzip. To remain
compatible I would leave a copy of the classes
in the old package with @Deprecated annotation.
I'd still propose to scope 'gzip', may be not with 'common' but with
something else
Cheers, Sergey
Christian
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
