camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Claus Ibsen" <claus.ib...@gmail.com>
Subject Re: [HEADS UP] Using verbs for the EIP actions
Date Sun, 23 Nov 2008 16:42:15 GMT
Hi

Yeah as well we have fluent builders we should have fluent "read load
the DSL" so it makes fluent English ;)

But I do see so many types needed to be renamed so if we could compile
the list then it would probably be max 10 and that is not to bad. And
if the compiler anyway spits out something to fix then this is the
best time to get the DSL aligned to proper fluent English routing
language

/Claus Ibsen
Apache Camel Committer
Blog: http://davsclaus.blogspot.com/



On Sun, Nov 23, 2008 at 5:22 PM, Roman Kalukiewicz
<roman.kalukiewicz@gmail.com> wrote:
> I believe we shouldn't have totally different jar for second API.
> Basically I would say, that it is 2.0 release, so it is OK to break
> API compatibility.
>
> Why should we support backward compatibility with just DSL while we
> don't support it with Processors (generics are removed), so what
> people have will not compile with new Camel anyway. Changes you
> propose are not hard to fix, so if fix is needed, then why should we
> care.
>
> I would rather discuss if this change is really needed. Honestly saing
> I don't care, but there is a small reason to keep it as it was -
> backward compatibility in the sense, that there will be less things to
> fix.
>
> For me split() or splitter() is not a big change. It is just the way
> we see our camel 'flows'. Are they commands to execute one after
> another (then split this) or they describe logical elements that build
> the flow (then there is a splitter). Anyway we should be consistent so
> if we have 'splitter' we should have 'processor' - not
> splitter().process(myLogic) like now.
>
> Romek
>
> 2008/11/21 Claus Ibsen <claus.ibsen@gmail.com>:
>> Hi
>>
>> If the DSL changes is very small then it's more or less just search/replace
>> - splitter => split
>> etc.
>>
>> I think it's overkill to create a 2nd .jar with the old stuff. How
>> should we maintain this?
>>
>> /Claus Ibsen
>> Apache Camel Committer
>> Blog: http://davsclaus.blogspot.com/
>>
>>
>>
>> On Fri, Nov 21, 2008 at 7:08 PM, Hiram Chirino <hiram@hiramchirino.com> wrote:
>>> ah.. gotcha..   but then you could not incrementally migrate projects.
>>>  I.e. Ihave 500 old camel routes.. and I want to migrate 50 of them
>>> for the next version of my app..
>>>
>>> On Fri, Nov 21, 2008 at 1:01 PM, Hadrian Zbarcea <hzbarcea@gmail.com> wrote:
>>>> The idea is to move it to a different jar, not a different package, to
>>>> maintain backwards compatibility.
>>>>
>>>> Comments and ideas always welcome!
>>>>
>>>> Hadrian
>>>>
>>>> On Nov 21, 2008, at 12:55 PM, raulvk wrote:
>>>>
>>>>> Hi, I was just following this thread and even though I am not a
>>>>> committer I thought it would be OK if I put it my 2 cents...
>>>>> Don't you think that moving the old noun-based DSL to a different
>>>>> package than the current one would defeat the purpose of
>>>>> backward-compatibility? If this was done, I believe that all current
>>>>> code would still need to be changed to reference the newly package
>>>>> that contains the old DSL, therefore disarming the
>>>>> backward-compatibility of this solution...
>>>>>
>>>>> Am I right?
>>>>>
>>>>> 2008/11/21 Hadrian Zbarcea <hzbarcea@gmail.com>:
>>>>>>
>>>>>> Interesting idea, but in that case, I'd rather put the old ones in
a
>>>>>> separate package.  Or put both dsls in separate jars (and use one
or the
>>>>>> other).
>>>>>>
>>>>>>
>>>>>> On Nov 21, 2008, at 12:23 PM, Hiram Chirino wrote:
>>>>>>
>>>>>>> I'm not sure how backward compatible we want to remain.  It could
be
>>>>>>> possible to put the new java DSL route builders in a new package
or
>>>>>>> class so that it is possible to one day provide a backward
>>>>>>> compatibility support.  Not that we have to do that day 1 of
the 2.0
>>>>>>> release..
>>>>>>>
>>>>>>> What do you think?
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Nov 21, 2008 at 8:38 AM, Jon Anstey <janstey@gmail.com>
wrote:
>>>>>>>>
>>>>>>>> Agreed. We shouldn't even be thinking of keeping two sets
of DSL
>>>>>>>> methods
>>>>>>>> for
>>>>>>>> the 2.0 release, would be too messy. I'd say go for it!
>>>>>>>>
>>>>>>>> BTW we've been keeping track of API breaks in the 2.0.0 release
notes
>>>>>>>> just
>>>>>>>> so users are aware of this
>>>>>>>> http://cwiki.apache.org/confluence/display/CAMEL/Camel+2.0.0+Release
>>>>>>>>
>>>>>>>> On Fri, Nov 21, 2008 at 4:26 AM, Willem Jiang
>>>>>>>> <willem.jiang@gmail.com>wrote:
>>>>>>>>
>>>>>>>>> Hi
>>>>>>>>>
>>>>>>>>> In the CAMEL-64[1], we are talking about using the verbs
for EIP
>>>>>>>>> actions.
>>>>>>>>> Current Camel's DSL and Spring configruation file are
using noun to
>>>>>>>>> define the routing rules.
>>>>>>>>>
>>>>>>>>> Such as
>>>>>>>>> from(seda:a).throttler(10).to(mock:result);
>>>>>>>>>
>>>>>>>>> <camelContext id="camel"
>>>>>>>>> xmlns="http://activemq.apache.org/camel/schema/spring">
>>>>>>>>> <route>
>>>>>>>>> <from uri="seda:a" />
>>>>>>>>> <throttler maximumRequestsPerPeriod="3" timePeriodMillis="30000">
>>>>>>>>> <to uri="mock:result" />
>>>>>>>>> </throttler>
>>>>>>>>> </route>
>>>>>>>>> </camelContext>
>>>>>>>>>
>>>>>>>>> it will be better if we make DSL like this
>>>>>>>>> from(seda:a).throttle(10).to(mock:result);
>>>>>>>>>
>>>>>>>>> As we discussed in the JIRA, it is impossible to make
the Spring
>>>>>>>>> schema
>>>>>>>>> support old nuns and new verbs at same time.
>>>>>>>>>
>>>>>>>>> Since we are working on Camel 2.0, it will be painless
if we directly
>>>>>>>>> move on to use the verbs instead of still supporting
nuns in DSL and
>>>>>>>>> Spring configuration.
>>>>>>>>>
>>>>>>>>> Any thoughts ?
>>>>>>>>>
>>>>>>>>> [1]https://issues.apache.org/activemq/browse/CAMEL-64
>>>>>>>>>
>>>>>>>>> Willem
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Jon
>>>>>>>>
>>>>>>>> http://janstey.blogspot.com/
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Hiram
>>>>>>>
>>>>>>> Blog: http://hiramchirino.com
>>>>>>>
>>>>>>> Open Source SOA
>>>>>>> http://open.iona.com
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Hiram
>>>
>>> Blog: http://hiramchirino.com
>>>
>>> Open Source SOA
>>> http://open.iona.com
>>>
>>
>

Mime
View raw message