classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [cp-patches] RFC: [Patch] rewrite of classpath/gnu/java/net/protocol


From: David Daney
Subject: Re: [cp-patches] RFC: [Patch] rewrite of classpath/gnu/java/net/protocol/http/*
Date: Tue, 13 Sep 2005 10:15:20 -0700
User-agent: Mozilla Thunderbird 1.0.6-1.1.fc3 (X11/20050720)

Chris Burdess wrote:
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.

Yes, I think it was a good choice as we were definitely feeling the pain from the old implementation.


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.

That is what I am doing.  Most of the code is good as is.  However...

The current patch goes only half way by removing-badness-from/rewriting the receiving portion. The eventual full solution would do the same for the sending portion.

Instead of fishing for advice on how to work around the current limitations of the implementation, I am trying to get comments on my patch to improve it.

David Daney.








reply via email to

[Prev in Thread] Current Thread [Next in Thread]