Wouldn't it affect basic things such as the file component which uses
endpoints such as
file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name}
and also the properties component and all camel placeholders such as
properties:{{cool.end}}
I don't really think the change is worth it if those kind of things
are affected.
On Wed, Jun 20, 2012 at 4:02 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
> 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
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
