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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
