Hi Oleg,
> 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.
If Sun's code were good enough, we wouldn't provide an alternative
HTTP implementation. Why should we sink to their level in other areas?
;-)
This morning I realized why I don't like the API<->Impl intermingling.
The software engineering classes I attended in the early nineties were
rather dull, but - apart from the "Chinese Principle" - there was one
golden rule I took with me, which was reenforced in other areas too:
Cyclic dependencies are bad.
The implementation necessarily has a dependency on the API, and by
letting API classes depend on implementation classes, we get a cyclic
dependency. Well, Sun has a cyclic dependency even between java.lang
and java.io, but that doesn't mean I have to like it.
Cyclic dependencies can't be avoided on a class level, since there
are no header files in Java. I'm used to avoid cyclic dependencies
on a package level in my code. For HttpComponents, I would be content
to avoid a cyclic dependency between the API and the impl part of the
source tree. I don't think that qualifies as "holier than the Pope".
But if it is unattainable, so be it. I've got so much refactoring
ahead of me, I don't insist on doing more.
> 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?
What's the difference between supporting something as part of the API
or as part of the implementation part? If there's a bug, we'll fix it.
If the class needs to be used by applications, such as DefaultHttpParams,
we'll keep the API stable in the implementation part too. In case of a
choice, I would rather move API classes to the impl part than vice versa.
> 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?
I doubt there will be one, whether the API depends on impl or not.
I just consider it an indication of a good design if API does not
depend on impl. But I've seen so many bad code, I won't loose sleep
over this topic if we get it right otherwise.
At the moment I can't tell how many dependencies we've got from API
to impl. Maybe I'll have a look at it after I finish the package
name change, which I'm about to tackle now.
cheers,
Roland
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
