[VOTE] Camel MUST use valid URIs for identifying and configuring Endpoints

[hadrian]

Using URIs to identify and configure Endpoints is a notable Apache Camel
innovation. This feature was present in Camel from its first release.
The 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
[2]
http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

[hadrian]

+1
Hadrian

On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release.
> The 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.
>
>

[Johan Edstrom-2]

+1, WIth the fact that converters exist, we aren't breaking anything in 2

/je

On Jun 20, 2012, at 10:29 AM, Hadrian Zbarcea wrote:

> +1
> Hadrian
>
> On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
>> Using URIs to identify and configure Endpoints is a notable Apache Camel
>> innovation. This feature was present in Camel from its first release.
>> The 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.
>>
>>

[Guillaume Nodet]

-1

I don't think camel endpoints are real Uris as they are not really
used to point to a resource, though they can fall back to a URI in
simple cases.  The fact that we use URI-like syntax is I think because
it's easy to use and quite easily understandable.  We could have use
json or whatever syntax here.  We could even support multiple syntax
(actually, json for configuring endpoints could make a lot of sense
too as in some cases, it would be even more readable).

I don't really see any problem with the way things work now, and
changing what works just for the sake of complying with a spec we
don't care about, is not really worth it imho.

This would also lead to less coherence, as for example, the property
placeholder syntax ${xxx} inspired from spring is used in various
place, not only uris, but also expressions and such.   That would
raise confusion.

On Wed, Jun 20, 2012 at 2:37 AM, Hadrian Zbarcea <[hidden email]> wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release. The
> 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
> [2]
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

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

[Christian Mueller]

+1
see my comments on [2].

Also because the Camel code base grows and grows because we got some good
contributions and implemented new features, making the core code base as
much easy as possible is an important thing IMO. Throwing away all the
hacks is a good possibility.
Also doing the same thing equal should be important for us and our users.
e.g. constantly using protocol://user@host:port instead of
protocol://host:port?username=xxx or so...
But this is another discussion... ;-)

Christian

On Wed, Jun 20, 2012 at 7:40 PM, Guillaume Nodet <[hidden email]> wrote:

> -1
>
> I don't think camel endpoints are real Uris as they are not really
> used to point to a resource, though they can fall back to a URI in
> simple cases.  The fact that we use URI-like syntax is I think because
> it's easy to use and quite easily understandable.  We could have use
> json or whatever syntax here.  We could even support multiple syntax
> (actually, json for configuring endpoints could make a lot of sense
> too as in some cases, it would be even more readable).
>
> I don't really see any problem with the way things work now, and
> changing what works just for the sake of complying with a spec we
> don't care about, is not really worth it imho.
>
> This would also lead to less coherence, as for example, the property
> placeholder syntax ${xxx} inspired from spring is used in various
> place, not only uris, but also expressions and such.   That would
> raise confusion.
>
> On Wed, Jun 20, 2012 at 2:37 AM, Hadrian Zbarcea <[hidden email]>
> wrote:
> > Using URIs to identify and configure Endpoints is a notable Apache Camel
> > innovation. This feature was present in Camel from its first release. The
> > 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
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
>

[Łukasz Dywicki]

+1 (non binding)

If we'll support all existing features I see no locks here.

Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org


Wiadomość napisana przez Christian Müller w dniu 20 cze 2012, o godz. 21:57:

> +1
> see my comments on [2].
>
> Also because the Camel code base grows and grows because we got some good
> contributions and implemented new features, making the core code base as
> much easy as possible is an important thing IMO. Throwing away all the
> hacks is a good possibility.
> Also doing the same thing equal should be important for us and our users.
> e.g. constantly using protocol://user@host:port instead of
> protocol://host:port?username=xxx or so...
> But this is another discussion... ;-)
>
> Christian
>
> On Wed, Jun 20, 2012 at 7:40 PM, Guillaume Nodet <[hidden email]> wrote:
>
>> -1
>>
>> I don't think camel endpoints are real Uris as they are not really
>> used to point to a resource, though they can fall back to a URI in
>> simple cases.  The fact that we use URI-like syntax is I think because
>> it's easy to use and quite easily understandable.  We could have use
>> json or whatever syntax here.  We could even support multiple syntax
>> (actually, json for configuring endpoints could make a lot of sense
>> too as in some cases, it would be even more readable).
>>
>> I don't really see any problem with the way things work now, and
>> changing what works just for the sake of complying with a spec we
>> don't care about, is not really worth it imho.
>>
>> This would also lead to less coherence, as for example, the property
>> placeholder syntax ${xxx} inspired from spring is used in various
>> place, not only uris, but also expressions and such.   That would
>> raise confusion.
>>
>> On Wed, Jun 20, 2012 at 2:37 AM, Hadrian Zbarcea <[hidden email]>
>> wrote:
>>> Using URIs to identify and configure Endpoints is a notable Apache Camel
>>> innovation. This feature was present in Camel from its first release. The
>>> 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
>>> [2]
>>>
>> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E
>>
>>
>>
>> --
>> ------------------------
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> FuseSource, Integration everywhere
>> http://fusesource.com
>>

[Christian Schneider]

+1 To aim for spec compliant URIs in camel 3. We should not try to
achieve this at all costs though. So if there are hard cases where we
would loose features we should discuss them in detail.

For properties the question is if they should be compliant URIs before
or after the replacement. Probably it is ok if they are only URIs after
the replacement.

Christian

Am 20.06.2012 02:37, schrieb Hadrian Zbarcea:

> Using URIs to identify and configure Endpoints is a notable Apache
> Camel innovation. This feature was present in Camel from its first
> release. The 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.
>
>

--

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

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

[Claus Ibsen-2]

-1



a)
I am happy with the current model, and DO NOT want any changes / implications
upon the Camel 2.x codebase. Its important for me that the current 2.x
codebase is kept stable as is.
Camel 2.10 is on the doorsteps, and Camel 2.x is now 3 years old. I
want to give reasurance to the community
that the 2.x is being kept as is (stability over changes).

Camel 3.0 is IMHO the place where changes can be discussed and
considered. Not the 2.x codebase.


b)
I have not yet seen any *real* end users call out on this and having issues etc.
In fact the current model is very successful, and people build many
Camel custom components
without any troubles. And likewise using these components with the
current model is
easy for people to understand and do. People dont complain about the
style/syntax of the endpoint uris.
They are readable, easy to configure etc. And people just type what
they want, without considering
if its a spec valid URI, or that they need to % decimal escape certain
chars etc.

See: http://en.wikipedia.org/wiki/Percent-encoding

c)
Reading the reasons that Guillaume Nodet posted makes me even more
convinced to keep the current model.

d)
I want components to be as compatible with as many Camel versions as possible.
And this change causes incompatibility.

e)
Others dont mind either; In fact if you type this URL in your webbrowser
http://www.google.dk/?q={{bla}}

or I type the URL valid with the other curly brackets decimal encoded
http://www.google.dk/?q=%7B%7Bbar%7D%7D

Then Google dont mind either, it gives me the same page, and result


Lets use on of the Camel examples then (from this page:
http://camel.apache.org/file2), by typing in our web-browser
http://www.google.dk/?q=file:bar?doneFileName=${file:name}.done

And then press ENTER. Google search result is shown, and the address
bar URL is changed to:

http://www.google.dk/?q=file:bar?doneFileName=${file:name}.done#hl=da&output=search&sclient=psy-ab&q=file%3Abar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&oq=file:bar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&aq=f&aqi=&aql=&gs_l=hp.12...0.0.0.9447.0.0.0.0.0.0.0.0..0.0...0.0.CdzGN56g1qA&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=1deded84056d2bf9&biw=1593&bih=951


If you look then the escaped URL returned from the .
file:bar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done

And that is really ugly. People should not need to type that.


And a good read about URL encoding is wikipedia
http://en.wikipedia.org/wiki/Percent-encoding

Quote from Wikipedia: Other characters in a URI must be percent encoded.
Reading that page (from wikipedia), says that other characters *must*
be encoded, and hence forcing people to use the ugly %NN style is
seriously reducing the ease of use with Camel.




On Wed, Jun 20, 2012 at 2:37 AM, Hadrian Zbarcea <[hidden email]> wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release. The
> 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
> [2]
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

--
Claus Ibsen
-----------------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.com
Author of Camel in Action: http://www.manning.com/ibsen

[Jon Anstey]

On Thu, Jun 21, 2012 at 3:53 AM, Claus Ibsen <[hidden email]> wrote:

> -1
>
>
>
> a)
> I am happy with the current model, and DO NOT want any changes /
> implications
> upon the Camel 2.x codebase. Its important for me that the current 2.x
> codebase is kept stable as is.
> Camel 2.10 is on the doorsteps, and Camel 2.x is now 3 years old. I
> want to give reasurance to the community
> that the 2.x is being kept as is (stability over changes).
>
> Camel 3.0 is IMHO the place where changes can be discussed and
> considered. Not the 2.x codebase.
>
>
> b)
> I have not yet seen any *real* end users call out on this and having
> issues etc.
> In fact the current model is very successful, and people build many
> Camel custom components
> without any troubles. And likewise using these components with the
> current model is
> easy for people to understand and do. People dont complain about the
> style/syntax of the endpoint uris.
> They are readable, easy to configure etc. And people just type what
> they want, without considering
> if its a spec valid URI, or that they need to % decimal escape certain
> chars etc.
>
> See: http://en.wikipedia.org/wiki/Percent-encoding
>
> c)
> Reading the reasons that Guillaume Nodet posted makes me even more
> convinced to keep the current model.
>
> d)
> I want components to be as compatible with as many Camel versions as
> possible.
> And this change causes incompatibility.
>
> e)
> Others dont mind either; In fact if you type this URL in your webbrowser
> http://www.google.dk/?q={{bla}}
>
> or I type the URL valid with the other curly brackets decimal encoded
> http://www.google.dk/?q=%7B%7Bbar%7D%7D
>
> Then Google dont mind either, it gives me the same page, and result
>
>
> Lets use on of the Camel examples then (from this page:
> http://camel.apache.org/file2), by typing in our web-browser
> http://www.google.dk/?q=file:bar?doneFileName=${file:name}.done
>
> And then press ENTER. Google search result is shown, and the address
> bar URL is changed to:
>
>
> http://www.google.dk/?q=file:bar?doneFileName=${file:name}.done#hl=da&output=search&sclient=psy-ab&q=file%3Abar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&oq=file:bar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&aq=f&aqi=&aql=&gs_l=hp.12...0.0.0.9447.0.0.0.0.0.0.0.0..0.0...0.0.CdzGN56g1qA&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf<http://www.google.dk/?q=file:bar?doneFileName=$%7Bfile:name%7D.done#hl=da&output=search&sclient=psy-ab&q=file%3Abar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&oq=file:bar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done&aq=f&aqi=&aql=&gs_l=hp.12...0.0.0.9447.0.0.0.0.0.0.0.0..0.0...0.0.CdzGN56g1qA&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf>
> .,cf.osb&fp=1deded84056d2bf9&biw=1593&bih=951
>
>
> If you look then the escaped URL returned from the .
> file:bar%3FdoneFileName%3D%24%7Bfile%3Aname%7D.done
>

Is this really the URI format we'll be changing to?? If so, I have to say

-1

I mean, this kind of syntax change can be hidden via external tools like
IDEs so it is fine from that respect... but from a pure Camel perspective I
don't think anyone will be able to write any Camel URI without memorizing
all those escape characters... which is a pretty painful thing. Ease of use
is one of the things that has made Camel as popular as it is today IMHO.

>
> And that is really ugly. People should not need to type that.
>
>
> And a good read about URL encoding is wikipedia
> http://en.wikipedia.org/wiki/Percent-encoding
>
> Quote from Wikipedia: Other characters in a URI must be percent encoded.
> Reading that page (from wikipedia), says that other characters *must*
> be encoded, and hence forcing people to use the ugly %NN style is
> seriously reducing the ease of use with Camel.
>
>
>
>
> On Wed, Jun 20, 2012 at 2:37 AM, Hadrian Zbarcea <[hidden email]>
> wrote:
> > Using URIs to identify and configure Endpoints is a notable Apache Camel
> > innovation. This feature was present in Camel from its first release. The
> > 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
> > [2]
> >
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: [hidden email]
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
>

--
Cheers,
Jon
---------------
FuseSource
Email: [hidden email]
Web: fusesource.com
Twitter: jon_anstey
Blog: http://janstey.blogspot.com
Author of Camel in Action: http://manning.com/ibsen

[James Strachan]

-1

I see no real reason to break stuff

On 19 June 2012 19:37, Hadrian Zbarcea <[hidden email]> wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release. The
> 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
> [2]
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

--
James
-------
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: jstrachan, fusenews
Blog: http://macstrac.blogspot.com/

FuseSource: integration everywhere

[Babak Vahdat]

Hi

-1

I've already once mentioned why I do think so:

https://issues.apache.org/jira/browse/CAMEL-4857

Babak

[iocanel]

Well, I don't have a binding vote anyway, but I am mostly curious on what's
the added value on doing such change.

I can see the some side effects like hard to read URIs etc, but I am
striving to see the added value.
Can you please provide some more info around that?

--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>

**
Blog: http://iocanel.blogspot.com
**
Twitter: iocanel
*

I'm +1 to the idea.   If we call it a URI, then it needs to be a URI.   If
this vote does not pass, then we would need to find a new name
(configuration string?) and update the documentation and such to reflect
that this is NOT a URI.

In particular, I'm +1 for full validation for 3.0.   For 2.x (including
porting back to 2.10 and maybe 2.9.x), we should allow the current URI's but
make sure a nice big fat warnging is displayed somehow so the user will know
that what they have entered is not a URI.

Dan


On Tuesday, June 19, 2012 08:37:33 PM Hadrian Zbarcea wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release.
> The 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.

--
Daniel Kulp
[hidden email] - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com

[Stan Lewis]

Yeah, URI escaping sucks, I'm -1 on changing the format and +1 on
changing the name of the configuration string to a quasi-URI,
URI-esque, wanna-be URI or whatever :-)

On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea <[hidden email]> wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release. The
> 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
> [2]
> http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

--
Stan Lewis
FuseSource
Email: [hidden email]
Web: http://fusesource.com
Twitter: gashcrumb

[Robert Davies]

-1 Camel does not need to use valid URIs - I see no real benefit for the user. I'm concerned about any changes that could affect existing users.

On 20 Jun 2012, at 01:37, Hadrian Zbarcea wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel innovation. This feature was present in Camel from its first release. The 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
> [2] http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

[Freeman-2]

-1, as it's working for a long time and stable.

We may discuss this change or rename the URI to a more appropriate  
name for Camel 3.x, but we should keep it as is for Camel 2.x line
Freeman
On 2012-6-20, at 上午8:37, Hadrian Zbarcea wrote:

> Using URIs to identify and configure Endpoints is a notable Apache  
> Camel innovation. This feature was present in Camel from its first  
> release. The 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
> [2] http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E

---------------------------------------------
Freeman Fang

FuseSource
Email:[hidden email]
Web: fusesource.com
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: http://weibo.com/u/1473905042

[Jeff Genender]

+1 - This has been a common complaint from a lot of users about not being a standard.  We just did a presentation and had people raising their hands asking why they are so different.  I think this would be great.

[Jeff Genender]

I want to add that AFAICT, there is no technical reason that we cannot support an official URI format *and* the current/legacy at the same time.  This should allow all parties to have their cake and eat it to.  This would effectively break nothing and the end user can choose a legacy format or standardized URL.

[Donald Whytock]

-1

The only real objection is that the word "MUST" begs the question "Or
else what?"  Will existing components in 2.x that use non-standard URI
structure not be carried into 3.x unless they're rewritten?  Will new
components that have non-standard URI structure be rejected out of
hand, the idea being that it's better to not have endpoint access to a
service than to have it through a non-standard URI?  What if the
non-standard nature of a component's URI reflects something native in
the service it talks to, so that it's unnatural for users of said
component who are familiar with the service to rework the URI to meet
Camel's requirements?

I know all this is part of the "details to be worked out later", but I
think these sorts of details should come sooner.

Don

[Hiram Chirino]

-1 This change would NOT be transparent to 2.x users.  Lets not hurt our
2.x Camel community! This should have been a discussion about how we could
improve Camel 3.x.

From my point of view, Camel is all about being flexible and an integrating
as many technologies as possible and avoid exclusive of approaches.  I
think that needs to continue even in how you configure endpoints.  You
might be able to convince me that most camel components SHOULD validate
their endpoint config uri using the Java URI class.  Or that components
should have a more formal way of expressing what endpoint config syntax it
expects.

java.lang.String is the most flexible and OPEN configuration java class we
have.  Lets keep it that way.

On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea <[hidden email]> wrote:

> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This feature was present in Camel from its first release. The
> 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.txt>
> [2] http://mail-archives.apache.**org/mod_mbox/camel-dev/201206.**
> mbox/%3C4FD60168.5090009%**40gmail.com%3E<http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E>
>

--

**

*Hiram Chirino*

*Software Fellow | FuseSource Corp.*

*[hidden email] | fusesource.com*

*skype: hiramchirino | twitter: @hiramchirino<http://twitter.com/hiramchirino>
*

*blog: Hiram Chirino's Bit Mojo <http://hiramchirino.com/blog/>*

*
*

*
*