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 :-) 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. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
