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 <[EMAIL PROTECTED]> wrote: > 2008/1/31, Hadrian Zbarcea <[EMAIL PROTECTED]>: > > 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
