Reading through this discussion, it seems like there are actually two levels to what is being discussed:
1) The validation rules for a proper URI and whether they are respected and enforced in Camel core. 2) The presentation of an endpoint's configuration as a URI to the user. The rules for #1 are clear and unmistakable as defined in RFC 2396. A given URI conforms to the specification or it does not. If it doesn't, then it's not a URI. You could call it something else like a "quasi-URI", but then it seems like there's an obligation to define the additional syntax and semantics of characters allowed beyond what's in a proper URI. Seems like a convention has developed over time for certain bits (e.g. properties), but without a concrete rule for what's allowed and whats not, consistency and validation get a little rough. Having a formal set of rules around this seems like a good thing. For #2, I think Guillaume's earlier comment on JSON as a representation of endpoint configuration is very appropriate. There can be multiple presentations of an endpoint's configuration which eventually reduce down to a URI. In our project, we use XML representations of endpoint config which reduce down to a URI representation under the covers. Perhaps the quasi-URI syntax that enjoys popularity today is a similar type of situation in that it can be a presentation of config to the user, but is always reduced to a proper URI when it hits core. cheers, keith On Jun 21, 2012, at 1:07 AM, Claus Ibsen wrote: > 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). > > > At first I though you was talking about Camel 3.0 changes only. But > reading this made me worry. > It seems that you want to force incompatibly between Camel 2.x and 3.0 > which is a NOT "a no brainer" for me. > > > >> In your example, it's just a matter of using parenthesis vs curlies and $ >> sign. > > I dont understand this. Guillaume pointed out a very valid example of > today with the file component. > This component has since Camel 1.5 supported specifying expression in > the uri configuration. > http://camel.apache.org/file > > Are you saying that > file://inbox?expression=backup/${date:now:yyyyMMdd}/${file:name} > > Is consider invalid, and that people need to type this differently? > > And what about the JBI component, the operation parameter is a JBI > naming style that uses curly brackets > http://camel.apache.org/jbi.html > > > >> 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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> >> > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen
