Hi Claus and Glen,

I agree that we might want to keep http3 for longer and the shared documentation is also a good reason to not rename. I also like Glen´s proposal to introduce a http3 component and perhaps deprecate the the http component. So people understand that http is not
the default component and they have the choice between http3 and http4.

Christian

Am 10.04.2012 05:41, schrieb Claus Ibsen:
Hi


On Mon, Apr 9, 2012 at 11:03 PM, Glen Mazza<gma...@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





--

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

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

Reply via email to