Roland Weber wrote:
Hi Oleg,
thanks for your feedback.
Hi Roland,
(1) First off, I think we can safely keep NIO out of the picture. The
process of opening a connection in non-blocking mode is completely
different from that in the blocking one.
* The user registers a request for a new connection with the connecting
I/O reactor:
Ok. My general line of thought was to implement the connection.open(...)
method so that it would take care of the registering. The question then
would have been whether to block the calling thread or whether to set
the connection to an intermediate state until the callback. Leaving it
out of the picture (for now) will make things easier.
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.
(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.
I think the data that
needs to be accessible directly from the connection is:
- open/closed, and if open...
- where is it connected to (ultimate target, not proxy)
- is it a secure connection
From that point of view, it should be possible to hide the tunnelling.
However, the client needs to be aware whether the connection is direct
or through a proxy, since requests sent to a proxy look different.
If opening the socket is the responsibility of the connection, then there
is no way around telling the connection whether it should go through a
proxy or not.
I need to think about this some more.
(4) We should start thinking about changing the socket factory interface
to enable support for detached sockets
https://issues.apache.org/jira/browse/HTTPCLIENT-475
Good point. Now that the factory is no longer in HttpCore, we're
not restricted to the 1.3 API anymore.
(4) Let us try to not over-engineer and keep stuff simple.
Fair. My problem currently is more the user safety than the
engineering part :-) An API that is easy to misuse is hardly
easy anymore, from a user perspective.
Agreed
interface: open while open
For performance optimizations in HttpAsync as well
as in a connection manager, it would be good if a
connection can be opened without being closed explicitly.
The idea is that it might be possible to avoid closing
and re-opening, for example if different target hosts
are accessed via the same proxy host.
Agreed. This might also help with connection proxying / tunneling.
I get a feeling that you would like to implement the calls
to the socket factories outside of the connection. This
raises the question of code reuse between HttpClient and
HttpAsync. I'll focus on HttpClient for now, that will be
tricky enough.
implementation: split open/close from read/write
May I suggest we leave this out for the first cut?
No problem. If we leave NIO out of the picture, there is
really no point at all to this split. The purpose would
have been to switch between blocking and non-blocking
opening of NIO connections.
Happy hacking
Thanks. I'll think about it some more today and tomorrow,
then get started next Wednesday or so.
Do not be shy and commit stuff as you go along. Once you are more or
less comfortable with the code just call for a review to get some
feedback, and then address the concerns that are raised in the process.
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]
