As I mentioned before, to me this is a no-brainer. We all advertised for
almost 5 years that Camel uses URIs. That is not true, it doesn't really.
Next there is the problem of parsing. In Camel it is ambiguous how a
configuration string (a la URI) looks like. You could say it's ok if the
parsing were done by a component, but it's not, it's done in the core,
it's error prone and issues creep in all the time. A couple of more
recent ones related to the use of '%' were the trigger for this discuss.
There is a log of unnecessary code (and buggy too) we could get rid of
and make things more predictable.
I understand the readability argument. I think however that if a
component designer payed attention to the spec when defining the URI, we
wouldn't be in this mess and URIs could be readable too. In parenthesis
(pun intended), parenthesis are unreserved chars (and hence safe to
use), while square and curly brackets are not. My suggestion: read the spec.
For edge cases encoding may be necessary, but that's known and expected
for any other technology out there, most notably REST that uses URLs
left and right. I don't see users being frustrated with Camel doing
what's pretty much expected and unambiguous.
Then there is the issue of tools and other libs using URIs. It is
impossible to generate a URI consumed by camel, because by using URIs,
the String form is encoded. That totally throws Camel (that encodes once
more) off.
Now validation. Yes, it's not completely separate. I meant it's separate
for the purpose of this discussion. Actually validating URIs is much
easier than validating Strings with an unknown syntax.
Hadrian
On 06/20/2012 08:43 AM, Guillaume Nodet wrote:
Well, I'm not sure why you consider that separate. I don't see the
point in forcing the user to use encoded characters which lessen the
readability if the uri is not correct at the end.
Also what's the drawback in encoding the uri ? At the end, the uri
encoding is correct, but it gives the user more ease of use.
Can you point to such drawbacks or problems using such uris ? (sorry
if I missed some previous discussions).
On Wed, Jun 20, 2012 at 2:27 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote:
Proper uri syntax and validation are 2 separate issues. This discussion is
about the syntax. Since it's just syntax (proper encoding) I don't see any
risk of loosing features and I agree we shouldn't.
Hadrian
On 06/20/2012 03:02 AM, Guillaume Nodet wrote:
Do you have any particular example ?
I know for example activemq uses uri in an extended way with
parenthesis and commas and I'm not sure they are completely valid.
If getting back to real uris means loosing some features, that needs
to be made clear.
On Mon, Jun 11, 2012 at 4:32 PM, Hadrian Zbarcea<hzbar...@gmail.com>
wrote:
This is not a new topic, but it looks like it's coming back in different
threads. Since this is is the underlying issue, I'd suggest clarifying
this
first.
At the core of the issue is a call to
UnsafeUriCharactersEncoder.encode(uri)
in DefaultComponent.createEndpoint(String), that made camel silently
accept
invalid URIs and then opened the gates to component writers using URIs
that
are not URIs. This behavior was there from the very beginning of Camel.
(I
refactored that code to introduce a deprecated from start preProcessUri
that
provided a path for cleaning up before camel-3.0, but that's a separate
topic).
To me, personally, using valid URIs for endpoints is a no-brainer, but I
sense that there is disagreement on that.
Thoughts?
Hadrian
