Hi Oleg,
> I think what client side NIO stuff really needs is an asynchronous
> version of the HTTP connection manager. The API I envisage should go
> along this line: (1) the consumer calls the connection manager and
> registers a request for a connection; (2) the connection manager checks
> whether there is an existent connection to the requested target host in
> the pool, and if not, initiates the process of creating one; (3) at some
> point of tine the connection manager calls back and returns an open
> connection; (4) and they all lived happily ever after. I do not see a
> need to have an interface to open NIO connections at all. This is a job
> of a connection manager.
That makes perfect sense. I was still too attached to HttpAsync,
where the connection needs to be opened after getting it. I think
the connection manager currently does not guarantee to return
open connections, but that's something we can fix.
>>> (3) I am still of an opinion that connection tunneling is a special case
>>> and should be treated as such. I think essentially the connection should
>>> be able to re-bind itself to a new socket. That is it. It should not be
>>> aware of any tunneling aspects.
>>
>> I haven't warmed up to the "socket binding" concept yet. In particular,
>> I'd hate to have a setSocket(...) method in the public interface. This
>> is just begging to be abused in unforeseen ways.
>
> I do not see it that way. It actually might be useful to be able to get
> access to the underlying socket, for instance, when tunneling non HTTP
> protocols via an HTTP proxy. I agree the base connection interface
> should not provide such a facility, but an optional interface may be the
> way to go.
How about this:
- The connection provides access to target host and proxy host, as
these two will be needed by advanced connection managers. It would
be an unnecessary burden on connection manager implementations to
maintain these values in a separate data structure.
- The connection does not open a socket, but expects it as part of
the open(...) and/or reopen(...) call.
interface ClientConnection extends HttpClientConnection {
HttpHost getTargetHost(); // or simply getHost()
HttpHost getProxyHost();
Socket getSocket();
boolean isSecure();
void open(Socket, boolean secure, HttpHost target, HttpHost proxy);
void reopen(Socket, boolean secure, HttpHost target, HttpHost proxy);
// optional, for convenience if there is no proxy
void open(Socket, boolean secure, HttpHost target);
void reopen(Socket, boolean secure, HttpHost target);
}
This allows the connection to control state transitions, like not
allowing a plain open() if it is already open. At the same time,
the socket creation stuff remains completely outside. Logic for
re-pointing the connection without re-opening the socket also remains
outside. The caller has the responsibility for passing the correct
target/proxy values along with the socket. Otherwise, connection
management will yield unpredictable results.
Giving public access to the socket also opens a door for abuse,
but that's something I can live with. Some JavaDoc comments on
this will be enough to ease my mind :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
