hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: [HttpCore] API vs. Implementation
Date Sat, 03 Feb 2007 12:25:39 GMT
On Fri, 2007-02-02 at 23:18 -0700, Bindul Bhowmik wrote:
> Hi Roland / Oleg,
> 
> On 2/2/07, Roland Weber <http-async@dubioso.net> wrote:
> > Oleg Kalnichevski wrote:
> >
> > > Here's my take. No impl classes in public methods (and hence
> > > interfaces). I do not see a problem with using impl class internally if
> > > they never get exposed to the consumer.
> >
> > There goes my idea of compiling the API classes separately
> > to detect dependencies on impl.
> 
> It is not required to actually compile the classes separately. Tools
> like Classycle[1] or JDepend[2] could be used.
> 
> >
> > Using anything internally does not match with my understanding
> > of an Application Programming _Interface_, but since it seems
> > I'm the only one who doesn't like it, let's leave it as it is.
> 
> [Non-binding thought]: I actually like to stick to the idea of having
> API and interfaces should be separate from implementation classes. I
> like to think that if APIs need to depend on implementations, then the
> APIs probably need to be expanded.
> 

Hi Roland / Bindul

I do not think we should try to be holier than the Pope. As far as I
know Sun uses non-public Sun specific classes all over the place in
JRE. 

We could make HeaderGroup and DefaultHttpParams public classes, or make
then inner classes instead, but personally do not see a lot of value in
doing so. Http service handlers in HttpCore NIO make a heavy use of
buffering primitives that I do not think we want to support as a part of
public API. Shall we make them all public, package private or inner?

We want people to be able to extend HttpCore and inject some application
specific implementation of interfaces, but do we ever want anyone to
provide a complete alternative implementation of HttpCore API? 

Oleg

> >
> > cheers,
> >   Roland
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: httpcomponents-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: httpcomponents-dev-help@jakarta.apache.org
> >
> >
> 
> 
> Regards,
> Bindul
> 
> [1] http://classycle.sourceforge.net/
> [2] http://www.clarkware.com/software/JDepend.html


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


Mime
View raw message