Splitting Network.URI from the network package

[Christian Maeder]

I would prefer option 1, too, that is keep network-uri independent from 
network.

(I also think, the version number for network-uri could start at 1.0.)

network-uri should be preferred over other "uri" packages [1]

Cheers Christian

[1] http://hackage.haskell.org/packages/search?terms=uri

Am 14.08.2014 15:49, schrieb Graham Klyne:
> On 13/08/2014 13:02, Michael Snoyman wrote:
>>> My apologies. Let me clarify. If the user doesn't already have a version
>>> >of network installed (e.g. via the HP), then building network is
>>> required
>>> >to build network-uri. This probably isn't a problem on Windows, if we
>>> >assume users already have an appropriate version of network through
>>> the HP.
>>> >It might be an inconvenience (e.g. longer build times) for users who
>>> don't
>>> >use the HP but still want to build network-uri (e.g for the
>>> maintainer of
>>> >network-uri:)  ).
>>> >
>>> >
>> Thanks for the clarifications Duncan and Johan. Yes, we should add a
>> con to
>> the option 2 that usage of network-uri will require network to be
>> available. I'd consider this a relatively low-impact con, since I highly
>> doubt there are many people out there who will want to use Network.URI
>> but
>> not also want to use network- at least transitively.
>
> Hmmm... there are reasonable uses of URIs (e.g. in on-disk XML and RDF
> processing) that do not necessarily require use of networking.  These
> may be a minority, but I think they're not so rare.
>
> Also, my experience in other languages is that one may work with a web
> application framework (via something like WSGI), there can lots of URI
> handling code without any direct use of networking.  Also, I do a lot of
> testing of URI handling code separately from any networking.
>
> I think removing the URI handling dependency on networking would be a
> Good Thing.
>
> #g
>
> (developer of a past version of network-uri.)
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>