Re: HttpCore connections
On Tue, 2006-09-19 at 16:12 +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... In HttpClient, the Connection class directly implemented all the functionality that was needed. In HttpCore, the HttpClientConnection interface started out in a similar fashion, providing basically all the methods we expected an application or any component to be interested in. If I got your intentions right this time, you are trying to change that. Instead of a full-blown abstraction for client connections, you want HttpCore to define a kind of adapter interface, which holds only those methods that are required within HttpCore. Defining a full-blown abstraction is left to HttpConn. The responsibility for opening a connection should be moved outside of HttpCore. Hence, the interface does not need to specify an open(...) method. HttpCore does not care where the connection points to, hence the interface does not need a getTargetHost() method. SocketFactory is only needed to open a connection, hence it is not needed in HttpCore. Precisely. 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. Have you considered ConnectionReuseStrategy? If opening connections is not the responsibility of HttpCore, then deciding on reuse vs. opening a new one shouldn't be either. 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. 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]
Re: HttpCore connections
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 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. 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? cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore connections
One more thing: if it can wait until Dec/Jan, I'll work on HttpConn. cheers, Roland - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: HttpCore connections
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]
