Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 209.85.160.45 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FE35784.1050004@gmail.com>
References: <4FE11B4D.6030405@gmail.com>
	<CAGZ-RD+0jY=nR_uJu-z577jsf+L0rzrJ7kbs6HBrqQPfGeBmCg@mail.gmail.com>
	<4FE35784.1050004@gmail.com>
Date: Thu, 21 Jun 2012 21:50:11 +0200
Message-ID: 
 <CAEQV+EHJt2ah0NyUtw2qAukFNj6NFxSDzQ9reoKdK4MpY31_8A@mail.gmail.com>
Subject: Re: [VOTE] Camel MUST use valid URIs for identifying and configuring
 Endpoints
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Well, if you want to have technical comments, you'd have to come up
with a technical solution first.
If you just say camel MUST be X, people will assume the possible
consequences and base their decision on it.  If that 's not the
consequences you had in mind, proposing a solution will definitely
lead to more accurate responses.

On Thu, Jun 21, 2012 at 7:19 PM, Hadrian Zbarcea <hzbarcea@gmail.com> wrote=
:
> Now finally something I could work with. More inline.
>
> Hadrian
>
>
> On 06/21/2012 12:41 PM, Hiram Chirino wrote:
>>
>> -1 This change would NOT be transparent to 2.x users. =A0Lets not hurt o=
ur
>> 2.x Camel community!
>
> I think it will will be transparent. It MUST. The intent is *precisely* t=
o
> not hurt the 2.x Camel community. I said it before. Again, this is not ab=
out
> how exactly a solution will achieve this goal.
>
>
>> This should have been a discussion about how we could
>> improve Camel 3.x.
>
> Isn't there a [discuss] thread that started on 06/11? No comments there
> until I started the [vote] thread (on 06/19, eight days later) for reason=
s I
> explained already. And it turns out that my suspicions were correct. I've
> seen this pattern before.
>
> All -1s on this thread are either non technical (of the "I don't want any
> change" kind) or assume a solution (lots of "%x%x" hurt my artistic
> feelings). I am perfectly confident we can find a solution that both
> supports the current syntax and is aesthetically pleasing.
>
> If anyone wonders if I am frustrated, yes I am. On the plus side, we now
> have an open discussion and we can talk about a solution.
>
>
>
>> =A0From my point of view, Camel is all about being flexible and an
>> integrating
>> as many technologies as possible and avoid exclusive of approaches. =A0I
>> think that needs to continue even in how you configure endpoints. =A0You
>> might be able to convince me that most camel components SHOULD validate
>> their endpoint config uri using the Java URI class. =A0Or that component=
s
>> should have a more formal way of expressing what endpoint config syntax =
it
>> expects.
>
> Agree. Perfect. The last part, I am not sure is necessary, but certainly =
an
> option.
>
>
>>
>> java.lang.String is the most flexible and OPEN configuration java class =
we
>> have. =A0Lets keep it that way.
>
> Agree. What I meant was String that conform to the URI spec. The api shou=
ld
> stay the way it is. Sorry for not being clear enough.
>
>
>>
>> On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea<hzbarcea@gmail.com>
>> =A0wrote:
>>
>>> Using URIs to identify and configure Endpoints is a notable Apache Came=
l
>>> innovation. This feature was present in Camel from its first release. T=
he
>>> definition of the URIs syntax in unambiguous and defined in RFC-2396 [1=
].
>>>
>>> Some components introduced along the way do not use valid URIs and this
>>> needs to be corrected. This vote is intended to formalize the apparent
>>> lazy
>>> consensus in the [discuss] thread [2] on the dev@ list. This vote
>>> reflects agreement with the principle only. If this vote passes the
>>> details
>>> of the solution will be fleshed out later.
>>>
>>>
>>> [ ] +1 Camel MUST use valid URIs for Endpoint configuration
>>> [ ] -1 Camel does not need to use valid URIs (please provide reason).
>>>
>>> Vote is open for at least 72 hours.
>>>
>>>
>>> --
>>> Hadrian Zbarcea
>>> Principal Software Architect
>>> Talend, Inc
>>> http://coders.talend.com/
>>> http://camelbot.blogspot.com/
>>>
>>> [1]
>>> http://www.ietf.org/rfc/**rfc2396.txt<http://www.ietf.org/rfc/rfc2396.t=
xt>
>>> [2] http://mail-archives.apache.**org/mod_mbox/camel-dev/201206.**
>>>
>>> mbox/%3C4FD60168.5090009%**40gmail.com%3E<http://mail-archives.apache.o=
rg/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E>
>>>
>>
>>
>>
>


--=20
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com