You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by Roland Weber <ht...@dubioso.net> on 2006/09/10 17:53:28 UTC
Re: [jira] Commented: (HTTPCORE-11)
Hi Oleg,
I'm confident we can find an interface that serves the need of
both NIO and Async without this ugly split. Maybe you can explain
how you want to open connections in the NIO case? Like in the
examples, let the application open the socket synchronously and
then simply use it in the NIO classes? Or will there be an "open"
call that just triggers an operation which completes only later?
Could we use the trick from the transmitter and receiver, where
the thread calling the operation is blocked until the background
thread has done the work? Would it help to redeclare "open" as
an operation that may complete asynchronously? Setting the target
and/or proxy host can be done immediately, and the meaning of
isOpen() could be changed, or an extra state can be introduced.
Or we declare "open" an optional operation that can throw an
UnsupportedOperationException, like Iterator.remove().
If it isn't called anyway, what does it matter if it's there?
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2006-09-17 at 03:08 +0200, Roland Weber wrote:
> Hi Oleg,
>
> > Actually I think HttpClientConnection and HttpServerConnection are not
> > very good names for those interfaces. I would prefer those interfaces to
> > be renamed to HttpOutgoingConnection and HttpIncomingConnection.
>
> I've checked RFC 2616. In section 1.3, these terms are defined:
>
> client
> A program that establishes connections for the purpose of sending
> requests.
>
> server
> An application program that accepts connections in order to
> service requests by sending back responses. [...]
>
> Section 1.4 also starts by introducing the terms client and server in
> the first paragraph. I think the sendXXX and receiveXXX methods are
> the most characteristic ones in the connection interfaces. The client
> side has methods to send requests and receive responses, while the
> server side has methods to receive requests and send responses. So
> I doubt you'll find more appropriate names, except maybe for inserting
> "side": HttpClientSideConnection, HttpServerSideConnection.
>
So be it. Let's stick to these names. At the end of the day they do not
matter much. There's a Russian proverbial saying: "Call me a pot just do
not put me in an oven"
> > If do
> > not object to such a change, would you mind if I spit the interface into
> > HttpOutgoingConnection (sans #open()) and HttpClientConnection for the
> > time being, so I could go ahead with my work on NIO extensions?
>
> I am warming up to the idea of moving the functionality for opening to
> an extra interface. A lot of our code deals with reading and writing only,
> and expects a connection that is already open. An extra interface would
> help to distinguish those parts of the code. I expect such a split to come
> back and haunt us when we deal with connection management, but if it helps
> to overcome the current roadblock, so be it.
As long as it happens before the API freeze I do not see that as much of
an issue. That's what API development is all about.
> I'm still looking for a good name for the extended interface. Most ideas
> result in uncomfortably long names. I hate those, as my editor is set to
> 80 columns, and out indentation style already wastes plenty of horizontal
> space. My current favorite is HttpClientConnectionBox... you have to open
> the box in order to use the connection :-)
>
I _really_ would love to resolve this problem by simply moving the
extended connection interface and its default impl to the HttpClient
module
interface o.a.httpclient.HttpClientConnection
extends o.a.http.HttpClientConnection {
void open(...);
}
However, I understand you may want to use this interface in HttpAsync
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> Actually I think HttpClientConnection and HttpServerConnection are not
> very good names for those interfaces. I would prefer those interfaces to
> be renamed to HttpOutgoingConnection and HttpIncomingConnection.
I've checked RFC 2616. In section 1.3, these terms are defined:
client
A program that establishes connections for the purpose of sending
requests.
server
An application program that accepts connections in order to
service requests by sending back responses. [...]
Section 1.4 also starts by introducing the terms client and server in
the first paragraph. I think the sendXXX and receiveXXX methods are
the most characteristic ones in the connection interfaces. The client
side has methods to send requests and receive responses, while the
server side has methods to receive requests and send responses. So
I doubt you'll find more appropriate names, except maybe for inserting
"side": HttpClientSideConnection, HttpServerSideConnection.
> If do
> not object to such a change, would you mind if I spit the interface into
> HttpOutgoingConnection (sans #open()) and HttpClientConnection for the
> time being, so I could go ahead with my work on NIO extensions?
I am warming up to the idea of moving the functionality for opening to
an extra interface. A lot of our code deals with reading and writing only,
and expects a connection that is already open. An extra interface would
help to distinguish those parts of the code. I expect such a split to come
back and haunt us when we deal with connection management, but if it helps
to overcome the current roadblock, so be it.
I'm still looking for a good name for the extended interface. Most ideas
result in uncomfortably long names. I hate those, as my editor is set to
80 columns, and out indentation style already wastes plenty of horizontal
space. My current favorite is HttpClientConnectionBox... you have to open
the box in order to use the connection :-)
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sat, 2006-09-16 at 13:29 +0200, Roland Weber wrote:
> Hi Oleg,
>
> > All right. We pretty much agree to disagree for now.
>
> So it would seem :-)
>
> > Could we at the
> > very least remove these three methods from the HttpClientConnection
> > interface?
> >
> > void setTargetHost(HttpHost targethost);
> > InetAddress getLocalAddress();
> > void setLocalAddress(InetAddress localAddress);
>
> I'm fine with that. They were on my death list, too.
> (I have to take the time for a Kill Bill double feature
> one of these days :-)
Cool. Consider them dead.
> Are you going to replace the open()
> method with one that takes a target (and optional proxy)
> argument then? Opening without a way to specify the target
> would be pretty pointless.
>
I suggest we deal with it in the course of resolving HTTPCORE-8
> I can't promise, but I'll try to come up with a new version
> of the HTTPCORE-8 patch soon. One that includes my ideas
> on how NIO could be made to fit in. And it has to be soon,
> as the season of little time for OSS programming is about
> to start.
>
Let me throw a couple of ideas at you (by posting a patch later this
evening). See if you can incorporate them into your work.
Cheers
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
> All right. We pretty much agree to disagree for now.
So it would seem :-)
> Could we at the
> very least remove these three methods from the HttpClientConnection
> interface?
>
> void setTargetHost(HttpHost targethost);
> InetAddress getLocalAddress();
> void setLocalAddress(InetAddress localAddress);
I'm fine with that. They were on my death list, too.
(I have to take the time for a Kill Bill double feature
one of these days :-) Are you going to replace the open()
method with one that takes a target (and optional proxy)
argument then? Opening without a way to specify the target
would be pretty pointless.
I can't promise, but I'll try to come up with a new version
of the HTTPCORE-8 patch soon. One that includes my ideas
on how NIO could be made to fit in. And it has to be soon,
as the season of little time for OSS programming is about
to start.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2006-09-15 at 15:39 +0200, Roland Weber wrote:
> Hi Oleg,
>
...
>
> > If do
> > not object to such a change, would you mind if I spit the interface into
> > HttpOutgoingConnection (sans #open()) and HttpClientConnection for the
> > time being, so I could go ahead with my work on NIO extensions?
>
> I would prefer if you used the UnsupportedOperationException for the
> time being.
>
Hi Roland,
All right. We pretty much agree to disagree for now. Could we at the
very least remove these three methods from the HttpClientConnection
interface?
void setTargetHost(HttpHost targethost);
InetAddress getLocalAddress();
void setLocalAddress(InetAddress localAddress);
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Roland Weber <ht...@dubioso.net>.
Hi Oleg,
sorry, I didn't get the message before my departure.
> NIO based connections are not opened in the same sense as blocking
> connections, rather they are bound to an open socket (or IoSession in
> case of MINA) by an I/O reactor.
I see. The socket is openend somewhere else and then "attached" to
the connection later on.
> In other words asynchronous connections
> are not capable of "opening" themselves, hence my desire to get rid of
> the open() method in the generic interface, because it is too blocking
> I/O specific.
And still, the opening of the socket has to be triggered somehow,
and the information where the socket is supposed to point to should
be made available too. Even though the connection can not open itself,
it can provide the target information, set a trigger, and block the
calling thread until the I/O reactor has bound a socket to it. Similar
to what is done for receiveResponseHeader and receiveResponseEntity
in the NIO data receiver, if I am not mistaken?
> UnsupportedOperationException is certainly an option, but should be the
> last resort in my opinion.
Agreed.
> Actually I think HttpClientConnection and HttpServerConnection are not
> very good names for those interfaces. I would prefer those interfaces to
> be renamed to HttpOutgoingConnection and HttpIncomingConnection.
I don't like these names. Connections are bidirectional, it's only the
way of establishing connections that distinguishes a connection on a
(client) socket from that on a server socket. At least that's what I keep
telling my students once a year :-)
I have no problem with the client/server in the name, because of the
association with server sockets. Also, the association to the client and
server side of an HTTP communication is obvious. But I don't mind searching
for better names. My first ideas are not really suitable, because they are
too long for my liking: HttpInitiatingConnection and HttpAcceptingConnection.
And I'm sure you don't like the "initiating", because it implies that the
connection is actively establishing itself, rather than waiting to be
bound :-)
> If do
> not object to such a change, would you mind if I spit the interface into
> HttpOutgoingConnection (sans #open()) and HttpClientConnection for the
> time being, so I could go ahead with my work on NIO extensions?
I would prefer if you used the UnsupportedOperationException for the
time being.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
Re: [jira] Commented: (HTTPCORE-11)
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Sun, 2006-09-10 at 17:53 +0200, Roland Weber wrote:
> Hi Oleg,
>
> I'm confident we can find an interface that serves the need of
> both NIO and Async without this ugly split. Maybe you can explain
> how you want to open connections in the NIO case?
Hi Roland
NIO based connections are not opened in the same sense as blocking
connections, rather they are bound to an open socket (or IoSession in
case of MINA) by an I/O reactor. In other words asynchronous connections
are not capable of "opening" themselves, hence my desire to get rid of
the open() method in the generic interface, because it is too blocking
I/O specific.
> Like in the
> examples, let the application open the socket synchronously and
> then simply use it in the NIO classes? Or will there be an "open"
> call that just triggers an operation which completes only later?
> Could we use the trick from the transmitter and receiver, where
> the thread calling the operation is blocked until the background
> thread has done the work? Would it help to redeclare "open" as
> an operation that may complete asynchronously? Setting the target
> and/or proxy host can be done immediately, and the meaning of
> isOpen() could be changed, or an extra state can be introduced.
> Or we declare "open" an optional operation that can throw an
> UnsupportedOperationException, like Iterator.remove().
> If it isn't called anyway, what does it matter if it's there?
>
UnsupportedOperationException is certainly an option, but should be the
last resort in my opinion.
Actually I think HttpClientConnection and HttpServerConnection are not
very good names for those interfaces. I would prefer those interfaces to
be renamed to HttpOutgoingConnection and HttpIncomingConnection. If do
not object to such a change, would you mind if I spit the interface into
HttpOutgoingConnection (sans #open()) and HttpClientConnection for the
time being, so I could go ahead with my work on NIO extensions? When you
come back from your business trip, we could try find a solution to
HTTPCORE-8 and probably do away with HttpClientConnection altogether in
the process or move it to the HttpClient module.
What do you think?
Oleg
> cheers,
> Roland
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org