hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roland Weber <http-as...@dubioso.net>
Subject Re: HttpCore NIO questions
Date Sun, 17 Sep 2006 16:24:39 GMT
Hi Oleg,

I'll combine my responses in this mail.

>>> AbstractIOReactor has code that deals with a server socket
>>> channel. So it is exclusively server-side? If that is the case,
>>> I would suggest a name change to AbstractServerIOReactor.
> 
> The SelectionKey.OP_CONNECT handling code will be added at some point.

I get it. If there is no server socket channel registered at the
selector, then key.isAcceptable() will never be true and no server
side code will ever be executed.

> Was this document of any use at all?
> 
> http://wiki.apache.org/jakarta-httpclient/HttpCoreNioApi 

Damn, I had forgotten about that. Yes, it would have been helpful :-(


>> [...HttpClientConnection.open() and where to put it...]
> 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(...);
> 
> }

I hate having the same class/interface names in different packages.
I remember trying to override an initialization method that was given
a Properties argument. I failed miserably, until I realized that it
wasn't java.util.Properties but a project specific Properties class.

> However, I understand you may want to use this interface in HttpAsync
> 
We could start with an HttpConn module. The decision whether we'll
release it independently or only as part of HttpClient is still
pending, after all. See also below.


> To make matters even worse we have the following feature request to take
> care of: 
> 
> https://issues.apache.org/jira/browse/HTTPCLIENT-475
> 
> This is yet another reason why I think there is no way around having a
> HttpClient specific HTTP connection and connection management interfaces
> and another motivating factor for me to reduce the connection management
> code in HttpCore to an absolute minimum.
>  
> SocketFactory in HttpCore is very likely to be my next victim.

I am considering to officially declare HttpAsync defunct and pulling it
from the website. It was always caught between a rock and a hard place,
since it has to use HttpCore but also needs to provide functionality
for which (synchronous) APIs will only be discussed as part of HttpClient.
Now that we are even removing functionality from HttpCore, the work that
I would have to accomplish in order to make HttpAsync functional is
just piling up more and more. And whatever is put into HttpAsync now
will need to be reconsidered once we're working on the corresponding
part of HttpClient or one of the other modules. I can't help thinking
that any time spent on HttpAsync at this stage is wasted.

cheers,
  Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: httpclient-dev-help@jakarta.apache.org


Mime
View raw message