Awesome. This is very similar to what we agreed upon yesterday with
Claus.
I personally much prefer the in/out terminology as it has pretty
clearly defined meaning in a few specs.
The 'original' term is a bit confusing and I would avoid it. It could
mean either that the original coming into the consumer, or original
coming into a processor, and I think we mean the latter. I am not
totally opposed to changing the method names, but this seems to me
just a renaming and since it would incur extra work for the users, I'd
rather keep it as is.
With cleaning up the implementation and the documentation, which could
be done now or post 2.0, I am pretty happy.
Cheers,
Hadrian
On Jul 14, 2009, at 5:06 AM, James Strachan wrote:
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/
