On Tue, Apr 10, 2012 at 8:47 AM, Christian Schneider <ch...@die-schneider.net> wrote: > 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 >
Well I would like to make it more clear to our end users that there is more http components than just http and http4. For example we also offer AHC and Jetty. In fact if you are already using Jetty, to lets say, proxy a http service, then it may be much more compelling to use jetty as both consumer and producer. They work well together and scale well with the async non-blocking routing engine. Likewise AHC is a very nice http client with a lot of tracking and it leverages the excellent Netty async framework. And it also scales with the non-blocking routing engine. Well in fact its only the old http component that is blocking. http4 is also non-blocking as well. I suggest we add a FAQ entry about the http components we offer, and a little detail about each. Then we add a noticable info bar at the various http components pointing to this FAQ, so our end users is more aware of the http components. Instead they may just use the http or http4 components because they dont realize that jetty and ahc is also there. > 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 > -- Claus Ibsen ----------------- CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com FuseSource Email: cib...@fusesource.com Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
