On 30/01/12 10:56, Christian Schneider wrote:
We could of course also have a spearate module for gzip.
At a time we talked about moving some more HTTP-centric interceptors
from rt/core to transports/common, may be fastinfoset ones.
Dan may have more ideas, I recall him referring to this common module.
The reason why I think about moving it to core is that it just contains
3 classes and does not have additional dependencies.
I've just moved a cors code from the jaxrs module, it does have 3
classes at the moment only but it does not quite belong to the main
jaxrs module.
rt/core can become quite lumpy, not a big issue probably...
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.
'encoding' or 'common.encoding' sounds good to me
thanks, Sergey
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
