On Sat, 2007-06-16 at 15:22 +0200, Roland Weber wrote: > Hi Oleg, > > > HTTPCORE-64: Do not create a new HTTP context per each request execution. > > Request handlers may need to persist some custom state information between > > invocations. > > That's going to become an interesting design issue. > When we discussed parent/child contexts last year, you > suggested that the application should put shared objects > into the different contexts to allow for shared data. > Let's wait and see what use cases we'll get. >
Yes, I think this should be the case. However, whereas protocol handlers in HttpCore base module do not impose any specific approach to managing the execution context, those in HttpCore NIO do, because event-driven API always assumes some kind of a context within which events occur. HttpService and HttpRequestExecutor simply take an instance of HttpContext as a parameter and leave the gory details of context management up to the caller. The user can create one context per connection or per request or have a context hierarchy of a sort. Clean and neat. We do not have the same flexibility in HttpCore NIO. So, if we use one context per connection approach we at the very least give the users an option to maintain state between request invocations, if so they desire. If we used the context per request approach we would make this impossible. Cheers, Oleg > cheers, > Roland > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
