Mailing-List: contact httpclient-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpClient Project" <httpclient-dev@jakarta.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Subject: Re: [jira] Commented: (HTTPCORE-11)
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpClient Project <httpclient-dev@jakarta.apache.org>
In-Reply-To: <450434F8.8040808@dubioso.net>
References: <1841839.1157832322767.JavaMail.jira@brutus>
	 <450434F8.8040808@dubioso.net>
Content-Type: text/plain
Date: Sun, 10 Sep 2006 18:36:09 +0200
Message-Id: <1157906169.21112.6.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

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