camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Remove Camel HTTP component in Camel 3.0?
Date Tue, 10 Apr 2012 03:41:23 GMT
Hi


On Mon, Apr 9, 2012 at 11:03 PM, Glen Mazza <gmazza@talend.com> wrote:
> I guess for those (and only those) components for which Camel wishes to
> maintain multiple versions (e.g., http3 & http4, mina1 & mina2), it might be
> best for such components to always have a version number as part of their
> names instead of renaming whatever the standard version becomes back to the
> unnumeric version; i.e., a new component http5 always remains named http5,
> whether its market share is a just starting out 5% or the mainstream 80%,
> because ultimately such a component is not so much about sending messages
> over HTTP as it is about using a specific version of the Apache HTTP library
> (and its version-specific options and settings) to do that task.  "http",
> OTOH, would be a useful name for a generic component whose underlying
> implementation is black-boxed and allowed to change.
>
> For that reason, if we wish to retain camel-http in 3.0 (which most do not
> want to do anyway making this point moot), I would probably recommend a
> rename to the more specific "http3" while having no component named "http".
>

Yeah I would actually prefer to not rename components even for Camel
3.0, as we will have end users
on both Camel 2.x and 3.x at the same time (and I guess some few on
Camel 1.x as well).

And with the state of how for example the documentation at the Camel
website is presented, then it will confuse
users which component is what. As its a shared website for the docs
among the versions of Camel.

I also agree we should add notes to the Camel documentation to refer
people to http4, mina2 etc. But I don't necessary think we should mark
these components as deprecated and to be removed. Http Client 3.1 and
Mina 1.x is still in very much use. Despite being EOL or whatever.

And btw Http Client 3.1 is still going strong. For example Spring
Integration 2.1.1 (their latest release). Uses that for their http
component
http://search.maven.org/#artifactdetails%7Corg.springframework.integration%7Cspring-integration-http%7C2.1.1.RELEASE%7Cjar

The same for Mule 3.2.1
http://search.maven.org/remotecontent?filepath=org/mule/transports/mule-transport-http/3.2.1/mule-transport-http-3.2.1.pom
They have the versions defined in a parent pom
http://search.maven.org/remotecontent?filepath=org/mule/mule/3.2.1/mule-3.2.1.pom





> Glen
>
>
> On 04/09/2012 04:24 PM, Christian Schneider wrote:
>>
>> If we rename http4 to http for camel 3.0 I think it is acceptable as it is
>> a major version.
>>
>> On the other hand if we do not do it then what would we do? Keep http4
>> forever and not have http. For new users this will look just weird.
>>
>> Christian
>>
>> Am 09.04.2012 22:04, schrieb Christian Müller:
>>>
>>> My 0,02 $:
>>> I would add a warning on page [1] that new user should prefer to use
>>> camel-http4 over camel-http (as we did it already for iBatis). Camel-http
>>> should mark as deprecated and will be deleted in Camel 3.x.
>>> I would *NOT* rename camel-http to camel-http3 and camel-http4 to
>>> camel-http. This will confuse our users.
>>>
>>> [1] http://camel.apache.org/http.html
>>>
>>> Best,
>>> Christian
>>>
>>
>
>
> --
> Glen Mazza
> Talend Community Coders
> coders.talend.com
> blog: www.jroller.com/gmazza
>



-- 
Claus Ibsen
-----------------
CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Mime
View raw message