On Tue, 2006-09-19 at 18:48 +0200, Roland Weber wrote: > Hi Oleg, > > >>I've had some time to relax and think about connections. > >>As a result, I would like to sum up what I think you are > >>trying to achieve. Please have a look through it and > >>correct me where I got you wrong... > >> [...] > > > > Precisely. > > Ok. Sorry for being so slow on the uptake. I got on the wrong > track when we discussed "turning the connection into a container". > The idea of my patch for HTTPCORE-8 was to keep the full functionality > and just split the responsibilities between the connection object and > the operator. > I'm fine with the new design. Let's do it. Axe the open(...) method, > and getTargetHost() along with it. But this shift of a rather basic > responsibility - opening connections - makes me feel even stronger > that HttpConn should be released independently from HttpClient. > No objections against initial development there, of course. We already > had that discussion. >
I am leaning toward using a similar modular setup for HttpClient as for HttpCore. Modules HttpConn, HttpCookie, HttpAuth can have different artifact ids (in Maven speak) and be packaged separately but released simultaneously. Anyways, separate release cycle for HttpConn, HttpCookie, HttpAuth remains an option to be discussed. > > I am trying to keep HttpCore as a minimalistic, transport agnostic > > protocol layer, that is usable with classic I/O sockets, NIO channels, > > abstract I/O transports such as MINA and what not. The job of HttpCore > > should be in my opinion to ensure RFC 2616 compliant serialization and > > deserialization of HTTP messages. > > The one thing we can't help is that it uses streams. But there's no > point in defining yet another I/O abstraction to be mapped to streams > and channels. > We might come up with an event driven version of HttpEntity at some point of time if there's a huge demand for such a feature. > > ConnectionReuseStrategy is not really needed for the client side. It is > > a must for the server side HttpService, though. It is used on the server > > side to determine whether a connection can be used for subsequent > > requests or it should be dropped in order to delimiter the response > > content. > > Ok, then it remains in HttpCore. > > Should we cancel HTTPCORE-8 and reopen HTTPCORE-11? > Redefine the objective of HTTCORE-8? Create a new issue? > I think HTTPCORE-8 is still perfectly valid. We will have to re-assign it to HTTPCLINET once we are done changing the HttpClientConnection interface. That's all. 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]
