On Fri, Jun 29, 2012 at 4:14 PM, Hadrian Zbarcea <hzbar...@gmail.com> wrote:
> Seriously Guillaume?
>
> You may have noticed that *this* [discuss] thread was opened 8 days
> *prior* to the vote. Initially that very few commented on. It's just that I
> learned history all to well to know how lazy consensus works in this
> community.
I do regret I have too many incoming emails every day to closely follow
everything, I try to keep up the way I can.
> Honestly, I think that was not very well communicated in the vote thread.
>> I can't bind myself to a very loose proposition without knowing the
>> consequences. I agree it would be better to have valid uris, but not at
>> all costs. Anyway, it had the nice benefit of getting everyone involved
>> though :-)
>>
> You're welcome! The [vote] did the trick didn't it?
Surely it did.
>
> I think forward compatibility is just something bound to break. We should
>> have backward compatibility, i.e. when we release something, ensure, that
>> it supports the old stuff and deprecate it. To be clear, I think it's
>> better to have 3.0 being uri compatible with 2.x, deprecate the old
>> support, then have 3.1 or 4.0 remove support for old uris, instead of
>> having 2.11 with new uri and 3.0 not supporting the old ones.
>>
> Maybe, maybe not. Depends on a few things, including for how long the two
> syntax flavors coexisted and what the users@ community would prefer. I
> admit making some assumptions about that, implicit in my proposal, that may
> prove wrong in the future. I repeat, I am not against supporting both, I
> only hoped at that time it would become unnecessary. But then again, I may
> be wrong, we'll see.
If other tools were to inter-operate with Camel (and that is more and more
>>> the case in my experience) we *must* enforce the standards. We can be
>>> lenient with the input we accept, but we must be strict in what we
>>> produce.
>>> To me the test is simple, if new java.net.URI(str) throws an exception,
>>> we've got work to do.
>>>
>>
>> Well, what really matters in that case is where the string comes from when
>> you build the uri from it. The xml / java DSL could accept invalid uri
>> and
>> those be encoded later, however, this may have side effects, as people may
>> expect to able to use what they gave earlier in various places.
>>
> A URI is, well, a URI, there's a spec for that that everybody understands.
> As there are specs for XML. Let's not talk hypothetically and focus on a
> solution instead.
>
Well, there aren't many solutions. Either users need to encode uri or we
need to change the components to not use reserved characters. I don't
really see any other solution for now, and both are not backward
compatible. But I'm still not sure what you have really have in mind as a
technical solution.
Also I don't think we've ever transformed any endpoint uri into a
java.net.URI, so as it was already stated, one solution is also to say
those are not uris anymore (and I don't say I want this solution, but that
still is one to consider).
> Cheers,
> Hadrian
>
>
>
>>
>>>
>>> Hadrian
>>>
>>>
>>>
>>> On 06/28/2012 06:24 PM, Christian Müller wrote:
>>>
>>> If instead of
>>>> <from
>>>> uri="file://inbox?move=backup/****${date:now:yyyyMMdd}/${file:**
>>>> **name}&*
>>>> *idempotentRepository=#**myStore"
>>>> />
>>>> or
>>>> from("file://inbox?move=****backup/${date:now:yyyyMMdd}/${**
>>>> **file:name}&**
>>>> idempotentRepository=#myStore"****)
>>>>
>>>>
>>>> I'm forced to write
>>>> <from
>>>> uri="file://inbox?move=backup%****2F$%7Bdate%3Anow%3AyyyyMMdd%****
>>>> 7D%2F%24%7Bfile%3Aname%7D&****idempotentRepository=%****23myStore"
>>>> />
>>>> or
>>>> from("file://inbox?move=****backup%2F$%7Bdate%3Anow%**
>>>> 3AyyyyMMdd%7D%2F%24%7Bfile%****3Aname%7D&****
>>>> idempotentRepository=%**
>>>>
>>>> 23myStore")
>>>>
>>>> this isn't a good user experience and a way I would like going down.
>>>>
>>>>
>>>> By thinking about a solution, I got some ideas:
>>>> <from uri="xxx" /> for valid URIs
>>>> <from endpoint="" /> for quasi URIs (change "endpoint" for whatever we
>>>> agreed)
>>>>
>>>> and in Java, we could have:
>>>> fromUri() for valid URIs (I didn't really it, because we have to do the
>>>> same with to, inOut, inOnly, ...)
>>>> from("") for quasi URIs
>>>>
>>>> But at the end, we still have to deal with not valid RFC-2396 URIs (like
>>>> Google it does). By writing this, I think we have to have some kind of
>>>> URI/endpoint string preprocessing which make sure the component/endpoint
>>>> receives a valid URI (and do not encode encoded URIs twice). And by
>>>> writing
>>>> this, I'm sure it's possible to handle this without introducing new DSL
>>>> elements or options. It may need some changes in the DefaultComponent
>>>> (not
>>>> sure), but it should not be a big deal for Camel 3.0.0 where we can
>>>> break
>>>> the API. Than we have one central place which is responsible for
>>>> encoding
>>>> the given endpoint string and forward a valid URI for further
>>>> processing.
>>>>
>>>> WDYT?
>>>>
>>>> Best,
>>>> Christian
>>>>
>>>>
>>>>
>>>> On Thu, Jun 21, 2012 at 8:09 PM, Rob Davies <rajdav...@gmail.com>
>>>> wrote:
>>>>
>>>> This sounds reasonable to me
>>>>
>>>>> On 21 Jun 2012, at 18:36, Hadrian Zbarcea wrote:
>>>>>
>>>>> Sounds perfect. That's exactly what I had in mind. You are proposing
>>>>> the
>>>>>
>>>>>>
>>>>>> extra setting, which I am perfectly fine with.
>>>>>
>>>>>
>>>>>> Thanks a bunch,
>>>>>> Hadrian
>>>>>>
>>>>>> On 06/21/2012 01:00 PM, Hiram Chirino wrote:
>>>>>>
>>>>>> How about we add setting to the camel context which controls if the
>>>>>>> 'UnsafeUriCharactersEncoder.****encode' method is used or not?
>>>>>>>
>>>>>>>
>>>>>>> That way folks that feel that their camel configurations MUST always
>>>>>>> use
>>>>>>> valid URI syntax can enable it. And the rest can continue to use the
>>>>>>> current behavior.
>>>>>>>
>>>>>>> Users are then in control.
>>>>>>>
>>>>>>> On Thu, Jun 21, 2012 at 8:53 AM, Hadrian Zbarcea<hzbar...@gmail.com>
>>>>>>>
>>>>>>> wrote:
>>>>>>
>>>>>
>>>>>
>>>>>> In theory yes, that's how it kinda worked for many years. In
>>>>>>> practice
>>>>>>>
>>>>>>>>
>>>>>>>> it
>>>>>>>
>>>>>>
>>>>> fails for all sorts of edge cases. The code that actually could be
>>>>>> very
>>>>>>
>>>>>>> simple and clear is riddled with all sorts hacks. Look at the code.
>>>>>>>>
>>>>>>>> Hadrian
>>>>>>>>
>>>>>>>>
>>>>>>>> On 06/21/2012 07:46 AM, Henryk Konsek wrote:
>>>>>>>>
>>>>>>>> It seems that you want to force incompatibly between Camel 2.x and
>>>>>>>>
>>>>>>>>> 3.0
>>>>>>>>>
>>>>>>>>> which is a NOT "a no brainer" for me.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Good point. We will end up with ugly and backward incompatible
>>>>>>>>> URIs.
>>>>>>>>>
>>>>>>>>> What about introducing "implicit URI encoding" term? Can't we just
>>>>>>>>> assume that semi-URIs strings passed to the Camel DSLs are in fact
>>>>>>>>> decoded URIs?
>>>>>>>>>
>>>>>>>>> In such case:
>>>>>>>>>
>>>>>>>>> import org.springframework.web.util.******UriUtils;
>>>>>>>>>
>>>>>>>>> // Decoded URI passed to the component.
>>>>>>>>> String decodedUri =
>>>>>>>>>
>>>>>>>>> "file://inbox?expression=******backup/${date:now:yyyyMMdd}/${****
>>>>>>>>>
>>>>>>>> **file:name}";
>>>>>
>>>>> // If we encode this URI we will end up with valid URI:
>>>>>>
>>>>>>> // file://inbox?expression=******backup/$%7Bdate:now:yyyyMMdd%******
>>>>>>>>>
>>>>>>>>> 7D/$%7Bfile:name%7D
>>>>>>>>> String encodedUri = UriUtils.encodeUri(decodedUri, "UTF-8");
>>>>>>>>>
>>>>>>>>> Maybe we just could validate that URI passed to the component is
>>>>>>>>> valid
>>>>>>>>> AFTER encoding it?
>>>>>>>>>
>>>>>>>>> String decodedUriFromDsl = ...
>>>>>>>>> String encodedUri = UriUtils.encodeUri(******decodedUriFromDsl,
>>>>>>>>>
>>>>>>>>> "UTF-8");
>>>>>>>>> assertValidUri(encodedUri);
>>>>>>>>>
>>>>>>>>> This will guarantee that Camel uses valid URIs but won't break
>>>>>>>>> contract of many existing components.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
