On Mon, May 25, 2009 at 9:00 AM, huntc <hu...@mac.com> wrote: > > Hi Claus, > > As per your blog request, I'd like to discuss the virtues of naming the > async method "async" vs treating your 2.0 functionality as a new > implementation of the existing "thread" method. > > When I think about concurrency I think about multiple threads of execution - > not whether something is asynchronous. You can have something being > asynchronous without it being multi-threaded e.g. Javascript's > XmlHttpRequest. > > Thread also implies just one thread. Perhaps renaming async to "threads" and > deprecating "thread" may be the way to go? Specifying "threads" without a > thread pool size should perhaps default to the number of processors + 1 as a > rule... (as per MINA?).
Good points. threads is a good name as well. And afterall the async DSL is capable of waiting for a response so it behaves like a single synchronous request/reply from the caller perspective. So using threads could be a better name. I have added your idea of the defaults for number of threads in the pool to the 2.x design page http://cwiki.apache.org/confluence/display/CAMEL/Camel+2.0+Design We have improved thread pool configuration on the roadmap for 2.1. > > Thoughts? > > Kind regards, > Christopher > -- > View this message in context: > http://www.nabble.com/Camel-2.0-Async-Findings---Roadmap-to-a-solution-tp23310165p23702159.html > Sent from the Camel Development mailing list archive at Nabble.com. > > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus
