I'll create a section in the evening with references to the associated ideas.
How are we handling the prototyping of ideas? Collaborate on code, reviews, (virtual) pair programming if we have a joint championship, etc. SVN is inflexible, but GitHub has the social element we need. Working on branches is the way to go, but "one idea = one branch" seems naïve because ideas can easily be interrelated. Shall we form "clusters" of related ideas and spawn off a branch for each cluster? For example, this core re-engineering + the two ideas that Claus mentioned can form an "idea cluster" (IC). The champions of the cluster can then create a branch each if they wish, merging onto the IC branch, and ultimately onto trunk if the implementation is approved by the community. Regards, *Raúl Kripalani* Apache Camel Committer Enterprise Architect, Program Manager, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> On Tue, Feb 19, 2013 at 9:31 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > On Tue, Feb 19, 2013 at 8:20 AM, Christian Schneider > <ch...@die-schneider.net> wrote: > > +1 > > > > I think one of the main things camel is missing is a routing engine. > > Like you wrote, currently each processor calls the next. Aspects like > > asynchronous behaviour, transaction and security are also > > implemented as processors. > > > > I think what we need is a runtime model of a camel route that represents > > the route without aspects. The aspects should then be executed > > by the routing engine without blowing up this model. > > > > This change is pretty severe though. I am not sure if we can refactor > > the camel core and keep it even somewhat compatible. > > I also fear that once we start these changes there is no way back and we > > might risk having an instable branch for a long time. So we have > > to reduce this risk in some way. > > > > > Its been on the Camel 3.0 roadmap for a long time > > Though its heading caption may have been chosen a better wording than > - More flexible routes at runtime > http://camel.apache.org/camel-30-ideas.html > > We had it as target for a long time, but as you said it safter to work > on this in a major release than on the 2.x architecture. > And hence why its not been done yet. > > And in term of the model, then we have missing pieces about the > inteceptors/onExceptions and whatnot. This is also on the roadmap for > Camel 3.0 > - Add OnException, Interceptor, etc. to JAXB model for a > CamelContextDefinition > > > > Christian > > > > On 19.02.2013 01:21, Raul Kripalani wrote: > >> Hello team, > >> > >> We use a recursive model in our routing engine to chain processors with > one > >> another to process exchanges. > >> > >> This results in lengthy stacktraces and increased memory usage due to > local > >> variable retention for longer than strictly needed, IMHO. This recent > >> question on Stack Overflow is a typical (short!) stacktrace: > >> > http://stackoverflow.com/questions/14734983/camel-ftp-intermittent-issue. > >> Debugging > >> it can be daunting for users. > >> > >> Moreover many infrastructural Processors are woven implicitly along the > >> processor chain. Maybe this logic should belong elsewhere (the routing > core > >> itself?). > >> > >> Now that the Camel routing model is consolidated, can we start thinking > >> about moving towards an iterative routing approach? I feel the recursive > >> approach worked wonders when Camel was still a baby and the architecture > >> was heavily evolving: basically any processor, at any point, could do > >> anything to the exchange. And everything was a processor. Flexible and > >> versatile! > >> > >> But now that the concepts are well rooted, I feel we need to formally > >> define "the routing process", rather than leaving it all up to > processors > >> to be assembled in the right order. > >> > >> I realize my proposal may sound somewhat abstract at this point, but > before > >> going to further length, I want to gauge if my concern is shared. > >> > >> What do you think? > >> > >> Raúl. > >> > > > > > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Open Source Architect > > http://www.talend.com > > > > > > -- > Claus Ibsen > ----------------- > Red Hat, Inc. > FuseSource is now part of Red Hat > Email: cib...@redhat.com > Web: http://fusesource.com > Twitter: davsclaus > Blog: http://davsclaus.com > Author of Camel in Action: http://www.manning.com/ibsen >
