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
le
Could you also explain to us the benefits in addition to the impacts ?
On Thu, Jun 21, 2012 at 8:29 PM, Hadrian Zbarcea wrote:
> Vote canceled. The community needs more time to understand the impacts. The
> consensus is that current users of camel 2.x must not be impacted by this
> change.
>
>
>
Vote canceled. The community needs more time to understand the impacts.
The consensus is that current users of camel 2.x must not be impacted by
this change.
Hadrian
On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
Using URIs to identify and configure Endpoints is a notable Apache Camel
innova
tp://camel.465427.n5.nabble.com/VOTE-Camel-MUST-use-valid-URIs-for-identifying-and-configuring-Endpoints-tp5714697p5714882.html
Sent from the Camel Development mailing list archive at Nabble.com.
Thanks Rob, sounds like the best course of action. Will do that.
Hadrian
On 06/21/2012 02:06 PM, Rob Davies wrote:
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 mo
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 someth
Don,
All valid questions. I agree that details should come sooner, but they
cannot come sooner than agreeing on a principle. That was the purpose of
this thread.
Hadrian
On 06/21/2012 12:39 PM, Donald Whytock wrote:
-1
The only real objection is that the word "MUST" begs the question "Or
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 C
-1 This change would NOT be transparent to 2.x users. Lets not hurt our
2.x Camel community! This should have been a discussion about how we could
improve Camel 3.x.
>From my point of view, Camel is all about being flexible and an integrating
as many technologies as possible and avoid exclusive o
-1
The only real objection is that the word "MUST" begs the question "Or
else what?" Will existing components in 2.x that use non-standard URI
structure not be carried into 3.x unless they're rewritten? Will new
components that have non-standard URI structure be rejected out of
hand, the idea be
-use-valid-URIs-for-identifying-and-configuring-Endpoints-tp5714697p5714857.html
Sent from the Camel Development mailing list archive at Nabble.com.
-1, as it's working for a long time and stable.
We may discuss this change or rename the URI to a more appropriate
name for Camel 3.x, but we should keep it as is for Camel 2.x line
Freeman
On 2012-6-20, at 上午8:37, Hadrian Zbarcea wrote:
Using URIs to identify and configure Endpoints is a not
-1 Camel does not need to use valid URIs - I see no real benefit for the user.
I'm concerned about any changes that could affect existing users.
On 20 Jun 2012, at 01:37, Hadrian Zbarcea wrote:
> Using URIs to identify and configure Endpoints is a notable Apache Camel
> innovation. This featur
Yeah, URI escaping sucks, I'm -1 on changing the format and +1 on
changing the name of the configuration string to a quasi-URI,
URI-esque, wanna-be URI or whatever :-)
On Tue, Jun 19, 2012 at 8:37 PM, Hadrian Zbarcea wrote:
> Using URIs to identify and configure Endpoints is a notable Apache Came
I'm +1 to the idea. If we call it a URI, then it needs to be a URI. If
this vote does not pass, then we would need to find a new name
(configuration string?) and update the documentation and such to reflect
that this is NOT a URI.
In particular, I'm +1 for full validation for 3.0. For 2.
Well, I don't have a binding vote anyway, but I am mostly curious on what's
the added value on doing such change.
I can see the some side effects like hard to read URIs etc, but I am
striving to see the added value.
Can you please provide some more info around that?
--
*Ioannis Canellos*
*
FuseS
Hi
-1
I've already once mentioned why I do think so:
https://issues.apache.org/jira/browse/CAMEL-4857
Babak
--
View this message in context:
http://camel.465427.n5.nabble.com/VOTE-Camel-MUST-use-valid-URIs-for-identifying-and-configuring-Endpoints-tp5714697p5714840.html
Sent from the
-1
I see no real reason to break stuff
On 19 June 2012 19:37, Hadrian Zbarcea 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 i
On Thu, Jun 21, 2012 at 3:53 AM, Claus Ibsen wrote:
> -1
>
>
>
> a)
> I am happy with the current model, and DO NOT want any changes /
> implications
> upon the Camel 2.x codebase. Its important for me that the current 2.x
> codebase is kept stable as is.
> Camel 2.10 is on the doorsteps, and Cam
-1
a)
I am happy with the current model, and DO NOT want any changes / implications
upon the Camel 2.x codebase. Its important for me that the current 2.x
codebase is kept stable as is.
Camel 2.10 is on the doorsteps, and Camel 2.x is now 3 years old. I
want to give reasurance to the community
t
+1 To aim for spec compliant URIs in camel 3. We should not try to
achieve this at all costs though. So if there are hard cases where we
would loose features we should discuss them in detail.
For properties the question is if they should be compliant URIs before
or after the replacement. Proba
+1 (non binding)
If we'll support all existing features I see no locks here.
Best regards,
Lukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Christian Müller w dniu 20 cze 2012, o godz. 21:57:
> +1
> see my comments on [2].
>
> Also because the Camel code base grows
+1
see my comments on [2].
Also because the Camel code base grows and grows because we got some good
contributions and implemented new features, making the core code base as
much easy as possible is an important thing IMO. Throwing away all the
hacks is a good possibility.
Also doing the same thin
-1
I don't think camel endpoints are real Uris as they are not really
used to point to a resource, though they can fall back to a URI in
simple cases. The fact that we use URI-like syntax is I think because
it's easy to use and quite easily understandable. We could have use
json or whatever synt
+1, WIth the fact that converters exist, we aren't breaking anything in 2
/je
On Jun 20, 2012, at 10:29 AM, Hadrian Zbarcea wrote:
> +1
> Hadrian
>
> On 06/19/2012 08:37 PM, Hadrian Zbarcea wrote:
>> Using URIs to identify and configure Endpoints is a notable Apache Camel
>> innovation. This fe
+1
Hadrian
On 06/19/2012 08:37 PM, Hadrian Zbarcea 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
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
27 matches
Mail list logo
