On Tue, 2006-09-05 at 21:26 +0200, Roland Weber wrote: > Hi Oleg, > > > I certainly do not have a problem with exposing the target host through > > the HttpClientConnection interface. We just have to make sure that > > HttpClientConnection cannot be (easily) put into an inconsistent state > > where the target host does not correspond to the remote address of the > > underlying socket. > > Agreed. > > > The trouble is that I would not want the HttpClientConnection interface > > to be directly coupled with java.net.Socket. At the same time I cannot > > think of an elegant way to re-attach the existing client connection to a > > new network socket. Let us think it over. > > So you think the solution I proposed with HTTPCORE-8 is not elegant. > I admit that it is slightly complex, but the objects have very well > defined responsibilities. I would also prefer a solution where the > calls to the operator do not have to be routed through the connection, > but it somehow matches the telephone analogy :-) >
Roland, I may not have fully grasped the concept but I felt the proposed solution would not work well with NIO where the process of establishing a connection was non-blocking. And yes, it is kinda complex ;-) So, my intention was to remove all methods from HttpClientConnection interface that have to do with connection initialization, provide a simple mechanism to bind the default HttpClientConnection impl to an arbitrary socket and then deal with HTTPCORE-8 > I am aware of two options for giving exclusive access to some of the > methods. The first one is what I've done in HTTPCORE-8: use an extra > callback object that is passed only to an entitled caller. The other > one is based on passing a secret "ticket" object to restricted calls, > which must have been set previously when the state became locked. > Then only the owner of the secret can perform modifications. > For the connections, I like the first solution better since it does > not pollute the connection interface. The user of the connection does > not even have to be aware of the connection/operator interaction. > But the operator is nonetheless exposed through the HttpClientConnection interface, right? So, every HTTP client connection would have to implement it even though not every kind of connection is capable of "re-opening" itself? 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]
