Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of willem.jiang@gmail.com
 designates 209.85.198.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=H7FZ5uUvgpv8i6rT8U56PHYrIhz9L5/0X8p6EKKmG5o92t2Epw0TRr9DHceEgJ2LT6
         zdzM7ZrMPitXBagwAokkCi5tzaKh1hqa96RKazjUmEr88rv7Zj80ycivav0k6Oc+Pmoa
         Mrh9mouALHFRDtcohvqnkAY7/7Kh2/iEayIbo=
Message-ID: <4A5C580C.6090700@gmail.com>
Date: Tue, 14 Jul 2009 18:03:56 +0800
From: Willem Jiang <willem.jiang@gmail.com>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
MIME-Version: 1.0
To: dev@camel.apache.org
Subject: Re: [DISCUSS] Semantics of IN and OUT
References: <A5F703FC-DAB2-44CE-A10D-C346FF5231B0@gmail.com>
 	<ec6e67fd0907100540tb0fd6b9u98c9b0e8ffefaf9c@mail.gmail.com>
 	<08620754-CF9D-4FFE-8008-953FEF3E0370@gmail.com>
 <ec6e67fd0907100816o6c6c14ai13a4d9f8d3dd5c64@mail.gmail.com>
 	<5380c69c0907120223i33d3b687l3df885c96cba5aab@mail.gmail.com>
 	<ec6e67fd0907130850l2700a452o4bc12babf3633587@mail.gmail.com>
 	<5380c69c0907130920t1c243aafwd3ce59ba844c570d@mail.gmail.com>
 	<ec6e67fd0907130933l536c4dd3r27293f172ab4ab60@mail.gmail.com>
 	<ec6e67fd0907130936we8b83bdme29d766202f2513c@mail.gmail.com>
 	<5380c69c0907131051i1ed6d881qf410ad5bf0727f16@mail.gmail.com>
 <ec6e67fd0907140005k1ca77983o79bceec58a73c1b8@mail.gmail.com>
In-Reply-To: <ec6e67fd0907140005k1ca77983o79bceec58a73c1b8@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

James Strachan wrote:
> 2009/7/13 Claus Ibsen <claus.ibsen@gmail.com>:
>>> Reading between the lines; are you really just trying to make folks
>>> use (what is currently called) "getOut()" and never try mutate what is
>>> currently called getIn()?
>>>
>>> i.e. so by default the "OUT" property is defaulted to a copy of IN
>>> that folks can change/mutate.
>>>
>>> (what we call these 2 methods is a separate discussion, whether its
>>> "in,out" or "originalMessage,message" or whatever
>>>
>> Hadrian and I had a chat today and we are clearing up some bits.
>> I am more on line with him now on the IN and OUT thing.
>>
>> So lets keep them.
>>
>> And use the time to fix the tiny bits such as the getOut() doing its
>> lazy creating a new empty message.
>> And whether its possible to let IN be immutable.
> 
> 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?
> 
+1 for this change.

For the InOnly Message Exchange Pattern, when we want to change the 
message , we just call the exchange's getMessage() and don't not care 
about if it's a in message or an out message.

For the ProduceTemplate sendMessage() method we can get the response 
message back from the exchange, by using exchange.getMessage() method.


Willem