gk at ninebynine.org
Mon Oct 25 10:32:21 EDT 2004
At 12:07 25/10/04 +0100, Simon Marlow wrote:
> > This would be a good time to make changes for consistency, and I'm
> > content
> > to update my code as needed.
> >> perhaps stringToURI instead of parseURI?
> > So the four parse*Uri* functions would become stringTo*URI* ?
> > That works for me. Almost. The problem is that the different names
> > refer
> > to variations in the string content, not differences in the final
> > value (otherwise a Read instance could be used, right?). I think a
> > <verb>*URI* here is more meaningful. e.g.
> > readURIReference
> > decodeURIReference
> > or suchlike. What's most Haskell-ish here?
>Ok. I suggest:
> - use upper-case URI consistently
> - replace the old parseURI with the new version. It has the same
> and doesn't completely differ in semantics. Besides, we're allowed
> to make changes to library interfaces in a major release. We'll be
> sure to document this change when 6.4 is released.
I'm happy with that if you are.
There's another possible change to consider, triggered by a late change of
terminology in the RFC2396bis specification, in which the term "relative
URI" is being replaced by "relative reference", to bring greater
consistency to use of the terms "identifier" and "reference". This all
-- 'parseRelativeUri' and
-- 'isRelativeUri' and
-- 'parseRelativeReference' and
-- 'isRelativeReference' and
I assume that the 'uri' in the datatype component names is
unchanged? uRIScheme looks unbelievable ugly, I think ;-) Simularly for
the parser values 'uri', 'uriReference', and also for 'uriToString',
Other changes, then, would be:
nullUri -> nullURI
Mark the compatible selector functions as deprecated (scheme, etc)
testUriReference -> testURIReference
-- This could be deleted, as it is not used or exported, but is a function
that I used for testing during development. I'm inclined to leave it.
parseUriAny -> parseURIAny
UriParser -> URIParser
relativeUri -> relativeRef
absoluteUri -> absoluteURI
-- not exported
> > Another area that I think might possibly be improved is the interface
> > for suppressing authority passwords in the string form of a URI. I
> > don't know, what do you think? The current interface is thus:
> > [[
> > -- |URI as instance of Show. Note that for security reasons, the
> > default
> > -- behaviour is to suppress any userinfo field (see RFC2396bis,
> > section 7.5).
> > -- This can be overridden by using uriToString directly with first
> > -- argument @id at .
> > ]]
>I don't have a strong opinion here. We should probably follow whatever
>the convention is.
There isn't one that I'm aware of.
As it happens, I was reviewing a haddock-ized version of the URI module
docs today (thanks to Sven providing a Windows build of Haddock), and that
particular interface didn't look as clunky as I feared it might. Mainly, I
wanted to ensure that a developer was going to make a conscious decision to
expose a password in a stringified URI. So I suggest leaving it unless
there's any objection.
Who's on the hook to make these changes? I'm happy to do them, but I note
that others are also improving this module now. I'd like to ensure the
test module is updated in sync with this.
BTW, I'm getting <cvs-libraries at haskell.org> messages now.
More information about the Cvs-libraries