Let's not get there (again). The community agreed already at least twice that this api is a good abstraction of what we try to do. As any abstraction it has to be properly documented. If it's not clear enough, that's where I would focus.
Hadrian On Sep 24, 2010, at 8:53 AM, Claus Ibsen wrote: > On Fri, Sep 24, 2010 at 2:51 PM, <patrice.god...@orange-ftgroup.com> wrote: >>> "But the Camel routing engine will automatic handle using IN if there >>> is no OUT message." >> >> So this is the magic behind! :-) >> I don't remember reading this anywhere previously and I was wondering how >> data was flowing from in to out messages. >> >>> >>> Working on IN is just much easier to explain and use for end users. >> >> Honestly it was confusing to me. >> Writing something to an "in" message to make it go "out" was really >> confusing to me. >> > > Yeah the API is not optimal there. We have debated this many times on > the dev forums. > > I personally would remove the IN and OUT and only keen one message. > getMessage() > > But the current API is kinda stuck due it been there since 1.0 and the > old legacy from JBI and whatnot. > > > >> >> >> ********************************* >> This message and any attachments (the "message") are confidential and >> intended solely for the addressees. >> Any unauthorised use or dissemination is prohibited. >> Messages are susceptible to alteration. >> France Telecom Group shall not be liable for the message if altered, changed >> or falsified. >> If you are not the intended addressee of this message, please cancel it >> immediately and inform the sender. >> ******************************** >> >> > > > > -- > Claus Ibsen > Apache Camel Committer > > Author of Camel in Action: http://www.manning.com/ibsen/ > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus
