Mailing-List: contact camel-user-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: camel-user@activemq.apache.org
Received-SPF: pass (athena.apache.org: domain of hzbarcea@gmail.com designates
 66.249.82.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:from:to:in-reply-to:content-type:content-transfer-encoding:mime-version:subject:date:references:x-mailer;
        b=cWFPX5hF6r/6+iZ3RG66A5lnhKO7F2YZC9qtSmlB+j2QfWTWsgPhiJzUIPl6d0OGrPzzSsch6wGC9vevib83Ellp255D2T8e6weL9q9qTyHc3NTllueaQsxV4UlR90OnY1ZLAn0G9W9WqT9VpCALvecDU9k0mIRMZK1sb4x2/b4=
Message-Id: <37907F20-E6DA-4FE4-9DEE-617F2461543E@gmail.com>
From: Hadrian Zbarcea <hzbarcea@gmail.com>
To: camel-user@activemq.apache.org
In-Reply-To: <af2843cd0802011015r3a4788feu5138bb877bceab81@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Subject: Re: in/out/fault messages discussion
Date: Fri, 1 Feb 2008 13:46:08 -0500
References: <f1c427510712050335j22a73fb1u619bbd258a06b30c@mail.gmail.com>
 <1D64AF3E-A69A-44DE-9DAB-F0EB238A8326@intalgent.com>
 <EBFEEEDA-E7B7-495C-803A-C1E169708DBE@gmail.com>
 <f1c427510801301052s26fd9441l1f51f77eb282812f@mail.gmail.com>
 <9A5229FD-DEA0-4F13-B201-E6866C572D38@gmail.com>
 <f1c427510801310205n1c935e95v9f212911237538b7@mail.gmail.com>
 <f1c427510801310248u75080918p24309226fc4fe427@mail.gmail.com>
 <4751B74B-BD39-4F97-92A9-DD62EAC330E7@gmail.com>
 <f1c427510801311018v34cd5a6exe8ad708570eb161a@mail.gmail.com>
 <af2843cd0802011015r3a4788feu5138bb877bceab81@mail.gmail.com>

This totally makes sense, especially given the fact that many  
components don't make that distinction.

I created camel-316 https://issues.apache.org/activemq/browse/CAMEL-316

Cheers
hadrian

On Feb 1, 2008, at 1:15 PM, Hiram Chirino wrote:

> I personally would like to get rid of the Fault message.  It should be
> possible ti interpret the output message as a Fault or interpret  an
> Exception as Fault.  Having an exception, a fault, and an output
> message be all valid outputs of a processor makes creating a DSL to
> handle all those cases MUCH more complex.
>
> Just my 2 cents.
>
> Regards,
> Hiram
>
> On Jan 31, 2008 1:18 PM, Roman Kalukiewicz <roman.kalukiewicz@gmail.com 
> > wrote:
>> 2008/1/31, Hadrian Zbarcea <hzbarcea@gmail.com>:
>>> Actually to Guillaume's point, I am strongly in favor of keeping the
>>> input.  And to be honest, I like the model the way it is, for many
>>> reasons.  One is that the model is very intuitive for people  
>>> familiar
>>> with certain standards, myself included, and the emtpy chairs don't
>>> bother me.  If I understand correctly you are not claiming that  
>>> there
>>> are features that the current model (vs yours) cannot support, just
>>> that your proposal will make it clearer.
>>
>> That is right. I believe that current model could be harder to
>> implement all different scenarios, that we don't have to think about
>> in mine, but everything could be done in the current one (with 3
>> messages available you can for sure implement everything that can be
>> done with 1, right? ;) ). I even believe that I was able to show,  
>> that
>> my solution also can handle all features we need.
>>
>>> Well, de gustibus non est disputandum.  If you really feel strongly
>>> about that, a vote is the way to settle it :).
>>
>> This is what I say from the very beginning. I was simply curious if  
>> my
>> impressions are common. But the fact is, that if I want camel to
>> change in this direction, I need creators of camel to be convinced to
>> this direction and I cannot do it alone (or I have to think about my
>> own one-message-branch ;) ). It looks that you are not really
>> convinced  ;)
>>
>> Anyway thank you for all your feedback
>> Roman
>>
>
>
>
> -- 
> Regards,
> Hiram
>
> Blog: http://hiramchirino.com
>
> Open Source SOA
> http://open.iona.com