David Daney wrote:
You would probably have a better chance if you threw out all the
inetlib classes and started from scratch with a pull-based client.
What are you talking about? I am not using inetlib.
The gnu.java.net.protocol.http package is the inetlib HTTP client.
I do agree with sections 3.2 and 4.1 of the GNU coding standards. I
do think that Classpath *should* be compatible with the reference
implementation (Sun's). I do think that Classpath *should* be robust.
It *should* "Avoid arbitrary limits ...". To do otherwise "... is not
acceptable in a GNU utility."
I agree with you. The inetlib HTTP client was not designed to fulfil
the contract of the URLConnection interface. We used it because it
fixed a lot of bugs in the previous implementation, not because it was
perfectly suited.
Your responses above just don't make sense to me. You seem to be
saying that because the current implementation of Classpath's HTTP
code is architecturally limited, I should come up with some private
re-implementation of the standard java runtime so that ... I don't
know what.
I am saying that because the current implementation of Classpath's
HttpURLConnection (based on inetlib) is architecturally limited with
respect to the URLConnection interface, you should reimplement it using
a different architecture and therefore different classes.
--
Chris Burdess
_______________________________________________
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
