Hadrian, do you know whether jetty:http://... is a valid URI? I'm to lazy to go through the entire spec. May you know it?
Christian On Wed, Jun 20, 2012 at 10:40 PM, Hadrian Zbarcea <hzbar...@gmail.com>wrote: > +1. Agree on all counts. All valid points. On the second bullet I think we > have even better options. > Thanks > Hadrian > > > On 06/20/2012 03:47 PM, Christian Müller wrote: > >> +1 for forcing valid URI from Camel 3.0 on warts if: >> - we can still support all options (if this is not the case, we have to >> discuss the concrete cases) >> - communicate this API breaking change in the Camel 3.0 release notes >> and provide the escaped char sequence for the most used chars (for >> convenience for our users) >> - URI's like jetty:http://...are valid (if not, we have to discuss >> this) >> - no change in Camel 2.x to force valid URI's (I think we all agree on >> this) >> >> If an influential number of users prefer to use invalid URI's for >> readability reasons, we could provide a converter utility class for their >> convenience (it's not my favor). But the DefaultComponent should assume >> valid URI's. >> >> And I also think validating options is an important, but different topic >> for a different thread... >> >> My 0.02$, >> Christian >> >> On Wed, Jun 20, 2012 at 6:29 PM, Hadrian Zbarcea<hzbar...@gmail.com> >> wrote: >> >> Guillaume, you pay a price no matter what, if you do something or if you >>> don't. I really don't want to talk about a solution, but the >>> DefaultComponent already has a @Deprecated preProcessUri(String uri) >>> intended to convert a current uri like String to an equivalent valid form >>> (and log the new form, so that users can update their code without much >>> pain). The only thing we need to do is to go through each component, >>> define >>> a valid form and implement preProcessUri (hopefully in 2.11.0) and then >>> remove it altogether in 3.0 (and only leave an external tool maybe for >>> those who migrate from old versions straight to 3.0). In your example, >>> it's >>> just a matter of using parenthesis vs curlies and $ sign. >>> >>> And by the way, nothing should be affected in 2.x, tests should continue >>> to work without changes, current syntax will be supported along a new, >>> valid syntax (and preProcessUri would provide the conversion internally). >>> >>> There are solutions. Is there willingness? Lazy consensus doesn't seem to >>> cut it, because discussions are avoided and then we come back to the same >>> thing over and over again. Now we have a vote, so hopefully we'll put >>> this >>> issue to rest soon. >>> >>> Cheers, >>> Hadrian >>> >>> >>> On 06/20/2012 11:31 AM, Guillaume Nodet wrote: >>> >>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>>> >>
