Hi
On 30/01/12 19:29, Daniel Kulp wrote:
On Monday, January 30, 2012 11:56:06 AM Christian Schneider wrote:
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.
I really have some mixed opinions on this. In "API" we have some similar
features similar to the gzip feature that really could be grouped into this,
but we have that split-package issue. For example, the FastInfosetFeature
kind of falls into the same basic idea and could likely be grouped into a
separate "features" bundle, but because we stuck it in org.apache.cxf.feature,
I have to leave it API. :-( (and the fact that the implementation of the
feature lives in org.apache.cxf.interceptor, also in API)
One positive from dropping this module is that we will have 1 less
module, and as Christian pointed out it won't affect users directly.
I guess it means the simpler config of features too...
Possible cons is that rt/core will start accumulating some more or less
common transport-specific code - but may be indeed some more material is
needed before getting a transport-specific module created for good...
Not sure :-). Whatever makes it better for 2.6 is good for me :-)
Cheers, Sergey
Dan
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
