Network.URI changes

[Graham Klyne]

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
>type,
>     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 
suggests that:
[[
--      'parseUri',
--      'parseUriReference',
--      'parseRelativeUri' and
--      'parseAbsoluteUri'.
--
--      'isUri',
--      'isUriReference',
--      'isRelativeUri' and
--      'isAbsoluteUri'.
]]

become:
[[
--      'parseURI',
--      'parseURIReference',
--      'parseRelativeReference' and
--      'parseAbsoluteURI'.
--
--      'isURI',
--      'isURIReference',
--      'isRelativeReference' and
--      'isAbsoluteURI'.
]]

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', 
'uriAuthToString'?

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.

#g
--

BTW, I'm getting <cvs-libraries at haskell.org> messages now.


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact