Hi Oleg, > It's great. I wish I had a half of your ability and patience to document > design alternatives I confront.
Thanks a lot. Although I have to admit it has little to do with patience. The problem just got so big that I couldn't keep the thoughts in my head anymore :-) I know it will save time in the end, so I do it now. > (1) "Applications must process responses as they arrive" > > If the problem cannot be resolved at the API level, an effort should be > made to provide a detection mechanism throwing an IllegalStateException > if an attempt is made to process responses in a wrong sequence. We could define a maximum timespan in which a handle has to be closed after the response is available. For blocking IO, there will be a thread waiting for the connection to become available again, so that thread can enforce the timeout and force-close the handle. > (2) red vs cyan As mentioned in reply to Mike's mail, I'll pick this discussion up next week. > (for instance, AsyncHttpProcessor _may_ no longer be required) For pipelining, the preprocessing/sending part has to be called by a different thread than the receiving/postprocessing part. HttpRequestExecutor just doesn't offer the interface to do that. I have one more idea to get rid of AsyncHttpProcessor with less intrusive changes to http-core than previous attempts. I'll tackle that when I'm back to coding in July or August. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
