Richard Kennard wrote:
What we have left appear to be some fairly small details. If I may summarise, you are saying...

Yes, I think that is true.
1) java.net.URL is discouraged, therefore we shouldn't support it in our API nor follow its naming convention (even though we'll sit alongside it in the java.net package)
I would agree with Alan on this. The problem with java.net.URL is that it contains a lot of legacy behavior which we cannot touch, much of which is contrary to the RFC specification for URIs. The more people are encouraged to use it, the more they will encounter these problems, and complain about them. URI on the other hand, was designed from the start to behave correctly with respect to the URI RFC, so the developers should be encouraged to use it, instead of URL.
2) We should move the 'apply' method into java.net.URI
In my view, apply() is fine where it is in this class.
3) Keeping the method names familiar to javax.servlet.ServletRequest developers is less important than neatness of code during method chaining

Again, and I suppose we are both coming from a Java SE perspective, but I would concur with Alan on this. I don't see a compelling reason to use excessively long method names, just to remain compatible with the servlet spec. This is a new API, and arguably there is no harm at all in looking a bit different from the servlet spec. We can defer the question though, if you feel particularly strongly about it.
I'm happy either way on 1 and 2, though I disagree with you on 3, but none of these seem like they should be major obstacles to CCC approval? With your permission, then, I'd like to leave them to the larger consensus?

I just have a couple more questions to ask relating to encoding and interpretation of '&' and ';' What if a string to be parsed uses ';' as separator, but contains '&' chars embedded within it,
which are not to be interpreted as separators?
If this situation could arise, would we then need a variant of parse() which takes a Separator char
and then only uses that char as the separator?

I think the docs should explicitly state that UTF-8 is the default character set used, which leads to another question. Should we have the possibility to specify the character set, perhaps in the toString() method? In my experience, in some parts of the world, particularly Asia,
other character sets are often used for web applications.
Regards,

Richard.


Reply via email to