Hi guys, I'm fine with anything y'all select for the name. I'm much more interested in figuring out how to get some of these resource issues settled and the two forks of this merged together so we have more people working together on this. Please see my thread on how to bring the Geronimo folks who are developing the other fork within the Geronimo sandbox. It would be a shame to have both groups working on the same issues.
Perhaps you want them in on this conversation as well before we diverge on the class names as well. Alex On Jan 29, 2008 5:55 PM, David M. Lloyd <[EMAIL PROTECTED]> wrote: > Mike Heath wrote: > [...] > > This topic came up on the IRC channel and David Lloyd (dmlloyd), Tuure > > Laurinolli (tazle), and I (mike_heath) were discussing better > > alternatives to the current design. The following is a summary of our > > conversation. > > And while Mike was typing up this excellent summary, the discussion > continued, so here's the next part. :-) > > > David posted this mockup as a possible future API > > http://rafb.net/p/P8GLTg85.html David wanted me to be sure to note that > > the class names in the mockup are just for purposes of explanation may > > change. > > So basically there's been a number of suggestions as to what to name > these things. Here are the two options: > > Name from pastebin Option 1 Option 2 > --------------------- -------------------- ---------------------- > AsyncHttpClient HttpClientFactory HttpClient > HttpRequestor HttpClient HttpConnector > HttpFuture HttpFuture HttpFuture > > So everyone liked HttpFuture. HttpRequestor is universally reviled (I > don't like that one either). Mike suggested option 2, Tuure thought of > Option 1. I pointed out that Option 2 might cause problems in that > people may confuse IoConnector with HttpConnector, though they represent > different concepts. Tuure stated that after typing HttpClientFactory a > few times, he started to like Option 2 some more. > > Of course nothing is decided until everyone has had a chance to weigh in. > > - DML >
