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 roman.kalukiewicz@gmail.com
 designates 64.233.170.190 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=czsYh4U8kn8pr3tP0n45IsT1wdD3/t850uH4cVPokWwQQ4Ru9oQjuXM1TM0/DntztzIlYDD2l0K4Fdf+NSjr4OjwVuZEz+71I8+PzBFvu3nkYkSWsLmjvy3ucucDromfuaZcSeT+I1ut7BPriyyPx7uskpy+4t14tzeTudNfyk8=
Message-ID: <f1c427510801311018v34cd5a6exe8ad708570eb161a@mail.gmail.com>
Date: Thu, 31 Jan 2008 19:18:21 +0100
From: "Roman Kalukiewicz" <roman.kalukiewicz@gmail.com>
To: camel-user@activemq.apache.org
Subject: Re: in/out/fault messages discussion
In-Reply-To: <4751B74B-BD39-4F97-92A9-DD62EAC330E7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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>

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