cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: [Discuss] Move gzip feature to core
Date Tue, 31 Jan 2012 07:07:34 GMT
I think I will move it to core for now but not yet change the package name.
So we stay compatible and still have one less module. For 3.0 I plan to 
move many of the Features to a new position.
We can then decide how to group them into jars.

For compatibility and the architecture the package name is more 
important than the jar anyway. A good design of the packages will allow
us the freedom to arrrange them into jars as we need. So we should 
discuss that soon to make a good decision for 3.0.

What is already really good with the gzip feature is that feature and 
interceptors are in the same package. I will try to do that for all 
features.
Currently many of the basic features are in the feature package while 
their interceptors are in the interceptor package. This is not so good 
as it does not allow
us to move them anywhere without breaking compatiblity or having split 
packages.

Christian

Am 30.01.2012 23:33, schrieb Sergey Beryozkin:
> 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


-- 
Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message