cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Beryozkin" <sergey.beryoz...@progress.com>
Subject Re: Proposal to deprecate CXF HTTP Binding
Date Tue, 20 Jan 2009 17:59:08 GMT


> Actually, I'll argue a bit. 2.1 will be live and maintained for some time.
> Anyone who really wants to use it can use 2.1. Can you think of a
> 2.2-specific feature that someone would want to combine with the old HTTP
> binding?

Not really...If we knew that no HTTP binding users migrated to CXF 2.2-SNAPSHOT (how likely
it is ?) then 
I guess we could indeed remove it for 2.2...

Are there any HTTP binding users out there who already started working with CXF 2.2-SNAPSHOT
? 

Cheers, Sergey

> 
> On Tue, Jan 20, 2009 at 12:30 PM, Benson Margulies <bimargulies@gmail.com>wrote:
> 
>> OK
>>
>>
>> On Tue, Jan 20, 2009 at 12:20 PM, Sergey Beryozkin <
>> sergey.beryozkin@progress.com> wrote:
>>
>>> Hi Benson
>>>
>>> I'd give HTTP Binding a bit more time to live, just declare it as
>>> deprecated and then remove it altogether in the next release.
>>> I think a number of users are actually using its client support and while
>>> I can say that we will attempt to
>>> provide a restful client api, I can't guarantee yet that it will be close
>>> to what HTTPBinding provides and even it will be of some reasonable quality
>>> in time for 2.2 release...
>>>
>>> Cheers, Sergey
>>>
>>>
>>>  +1 to deletion from the trunk for 2.2.
>>>>
>>>> On Tue, Jan 20, 2009 at 11:21 AM, Sergey Beryozkin <
>>>> sergey.beryozkin@progress.com> wrote:
>>>>
>>>>  Hi,
>>>>>
>>>>> I'd like to propose to have CXF HTTP Binding deprecated for the
>>>>> following
>>>>> reasons :
>>>>>
>>>>> 1. It's not mantained at all
>>>>> 2. CXF implements JAXRS which offers superior options toward building
>>>>> restful services
>>>>> 3. It adds to the overall build time and distribution size
>>>>> More specifically, I'd like to suggest that we formally declare it being
>>>>> deprecated when 2.2 is released
>>>>> which will give us an option to eventually remove it from the trunk,
>>>>> once
>>>>> we have the proper client api support.
>>>>>
>>>>> Thoughts ?
>>>>>
>>>>> Cheers, Sergey
>>>>>
>>>>>
>>>>
>>>
>>
>

Mime
View raw message