Well, if you want to have technical comments, you'd have to come up with a technical solution first. If you just say camel MUST be X, people will assume the possible consequences and base their decision on it. If that 's not the consequences you had in mind, proposing a solution will definitely lead to more accurate responses.
On Thu, Jun 21, 2012 at 7:19 PM, Hadrian Zbarcea <hzbar...@gmail.com> 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> >>> >> >> >> > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
