Proposal: splitting the network package

[Graham Klyne]

Hi all,

I'm late picking up on this.  I agree the Parsec dependency means it makes sense 
to separate the URI package from other network functions.  I don't know if 
there's a strategy for backwards compatibility of existing software that uses 
Network.URI.

On 09/01/2013 12:17, Conrad Parker wrote:
> Yes, but then the "uri" package currently only defines one module, Text.URI:
>
> http://hackage.haskell.org/packages/archive/uri/0.1.6/doc/html/Text-URI.html
>
> which is mostly similar and incompatible with Network.URI:
>
> http://hackage.haskell.org/packages/archive/network/2.4.0.1/doc/html/Network-URI.html
>
> Network.URI more completely implements the RFCs in that it handles
> relative and absolute URIs, and URI normalization.
>
> Text.URI includes a few functions for parsing (key,value) pairs for
> CGI query parameters, which iirc is not actually part of the URI
> specification, but rather part of the CGI conventions. I think these
> query parameters are better handled by the "cgi" package, or by any of
> the web frameworks (Yesod, Snap etc.).
>
> I think the only sensible way to use the "uri" package name would be
> to replace it (ie. remove Text.URI and add Network.URI).

FWIW, when I originally implemented URI, the interface was based on an existing 
package, but I don't recall exactly which.  Some changes were made to 
accommodate additional functionality, but with new function names.  Old function 
names were retained, but deprecated, for backwards compatibility.

I mention this because it suggests a possibility that the newer package might be 
tweaked to be a possible compatible replacement for the other.

At this stage in Haskell/HP life, I'd place a high premium on backwards 
compatibility - having existing software break because other packages don't pay 
sufficient attention to this issue is a factor that IMO impedes wider take-up of 
Haskell as a serious application development platform.  I see this discussion is 
a symptom of that.

#g