If you vote had more detail about what you was considering, then artistic feelings wouldn't have come into it :) Why don't you close this vote - and open a new discussion (with more detail?) - so we can try reach a consensus
On 21 Jun 2012, at 18:19, Hadrian Zbarcea wrote: > Now finally something I could work with. More inline. > > Hadrian > > On 06/21/2012 12:41 PM, Hiram Chirino wrote: >> -1 This change would NOT be transparent to 2.x users. Lets not hurt our >> 2.x Camel community! > I think it will will be transparent. It MUST. The intent is *precisely* to > not hurt the 2.x Camel community. I said it before. Again, this is not about > how exactly a solution will achieve this goal. > >> This should have been a discussion about how we could >> improve Camel 3.x. > Isn't there a [discuss] thread that started on 06/11? No comments there until > I started the [vote] thread (on 06/19, eight days later) for reasons I > explained already. And it turns out that my suspicions were correct. I've > seen this pattern before. > > All -1s on this thread are either non technical (of the "I don't want any > change" kind) or assume a solution (lots of "%x%x" hurt my artistic > feelings). I am perfectly confident we can find a solution that both supports > the current syntax and is aesthetically pleasing. > > If anyone wonders if I am frustrated, yes I am. On the plus side, we now have > an open discussion and we can talk about a solution. > > >> From my point of view, Camel is all about being flexible and an integrating >> as many technologies as possible and avoid exclusive of approaches. I >> think that needs to continue even in how you configure endpoints. You >> might be able to convince me that most camel components SHOULD validate >> their endpoint config uri using the Java URI class. Or that components >> should have a more formal way of expressing what endpoint config syntax it >> expects. > Agree. Perfect. The last part, I am not sure is necessary, but certainly an > option. > >> >> java.lang.String is the most flexible and OPEN configuration java class we >> have. Lets keep it that way. > Agree. What I meant was String that conform to the URI spec. The api should > stay the way it is. Sorry for not being clear enough. > >> >> On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea<hzbar...@gmail.com> wrote: >> >>> Using URIs to identify and configure Endpoints is a notable Apache Camel >>> innovation. This feature was present in Camel from its first release. The >>> definition of the URIs syntax in unambiguous and defined in RFC-2396 [1]. >>> >>> Some components introduced along the way do not use valid URIs and this >>> needs to be corrected. This vote is intended to formalize the apparent lazy >>> consensus in the [discuss] thread [2] on the dev@ list. This vote >>> reflects agreement with the principle only. If this vote passes the details >>> of the solution will be fleshed out later. >>> >>> >>> [ ] +1 Camel MUST use valid URIs for Endpoint configuration >>> [ ] -1 Camel does not need to use valid URIs (please provide reason). >>> >>> Vote is open for at least 72 hours. >>> >>> >>> -- >>> Hadrian Zbarcea >>> Principal Software Architect >>> Talend, Inc >>> http://coders.talend.com/ >>> http://camelbot.blogspot.com/ >>> >>> [1] >>> http://www.ietf.org/rfc/**rfc2396.txt<http://www.ietf.org/rfc/rfc2396.txt> >>> [2] http://mail-archives.apache.**org/mod_mbox/camel-dev/201206.** >>> mbox/%3C4FD60168.5090009%**40gmail.com%3E<http://mail-archives.apache.org/mod_mbox/camel-dev/201206.mbox/%3C4FD60168.5090009%40gmail.com%3E> >>> >> >> >>
