2009/7/14 Claus Ibsen <claus.ib...@gmail.com>: >> I think we're kinda mostly on the same page (though saying it in >> different ways). BTW I'm taking off my devils advocate hat now :)... >> >> What we're agreeing on I think is that; >> >> * getIn() should be immutable (when folks try to change it we can >> throw the exception and describe how getOut() should be used to change >> the message) - to prevent folks using the old code (which will require >> code changes). >> * having the original immutable message available is handy; but mostly >> folks should concentrate on the 'out' (current name today) >> * the out should be automatically populated with a clone of the IN (to >> avoid all that pain with checking if there's an out or an in, or the >> possible loss of headers etc. Internally we can use a CopyOnWrite >> facade to reduce the cost of potentially copying a message which is >> not actually mutated. >> >> Given that; I think we're mostly agreeing. However given the confusion >> of getIn() and getOut() I'm wondering if actually your previous idea >> of changing the api of exchange to have a getMessage() which returns >> the thing a processor should be changing; then having a >> getOriginalMessage() (which can be null if you are the first in the >> chain) might reduce the amount of confusion? >> >> i.e. after sleeping on it, I'm warming to the idea of renaming getIn() >> -> getOriginalMessage() and getOut() -> getMessage(). (Or maybe >> getInputMessage() for getIn()?) >> >> Thoughts? > > Very good thoughts James. I think all this will removes many obstacles > and confusing for new users to Camel. > > Now even the AggregationStrategy is less tricky to use as you will > know that using getMessage gets what you are looking for. > > Maybe we should create a wiki page at Camel where we can outline the > API proposal and ideas for the message facade.
Yeah. BTW we could leave getIn() and getOut() & try implement the ImmutableWrapper and CopyOnWriteFacade for In/Out respectively and try them out inside the current API - before we go ahead with any kind of renaming of getIn() and getOut(). Maybe we could even keep getIn() / getOut() around for 2.0 (and zap in 2.1) and leave deprecated and make them just delegate to the new method names (say getInputMessage() and getMessage()). The deprecated message could then describe how folks typically should switch getIn()/getOut() to using getMessage() unless they really really want the immutable input message getInputMessage(). -- James ------- http://macstrac.blogspot.com/ Open Source Integration http://fusesource.com/
