I think the core should focus on speed, consistency, reliability and last extensibility; Camel has a nice traction but we don’t want to see “strange” bugs from new features if that makes sense as a long windy sentence…..
> On Apr 4, 2016, at 9:36 AM, Matt Pavlovich <mattr...@gmail.com> wrote: > > > > On 3/24/16 3:27 PM, Raul Kripalani wrote: >> On Thu, Mar 24, 2016 at 5:24 PM, Krzysztof Sobkowiak < >> krzys.sobkow...@gmail.com> wrote: >> >>> I think, the way to Camel 3 should also include the renovation of the Core >>> (if really necessary) or even rewriting and >>> making it more asynchronous, e.g. using rx.java (the later can be >>> eventually part of Camel 4 roadmap if too dangerous >>> for Camel 3). >>> >> This also relates to the concurrency model. Camel revolves around the idea >> that more threads == more performance. Our processing actually >> hijacks/piggy-backs the threads of the 3rd party library of the component >> (Netty, Jetty, Spring JMS, etc. threads), and this is not good. One just >> needs to look around: reactive programming, coroutines, event loops, >> generators, goroutines (in Go), etc. to realise we're kinda obsolete by now. > "Obsolete" by what standard? >> The async routing engine was a step in the right direction, but most >> components don't even support it. >> >> Now that we know the reactive programming model is here to stay and it >> wasn't a fad, I feel we should definitely go in that direction. We should >> look at Akka, RxJava and the Reactive Streams [3] spec. > I expect there will be long term valuable pieces pulled from reactive > programming, just as there are from virtually every new "paradigm" that pops > up every few years-- but there will also be a balance of "doesn't meet the > hype". Anyone remember AOP (Btw-- which now has 3-4 sub-derivatives)? I > suggest letting the dust settle to see what the benefits-tradeoffs matrix > looks like before committing to overhauling Camel core. > > -Matt
