Kazu Yamamoto | 8 Jan 07:30 2013
Picon

Proposal: splitting the network package

Hello,

The network package contains both socket modules and a URI
module. They are in different level. Since new features are actively
added to the socket modules, we may want to install a new network
package even though Haskell Platform includes it. However, the
Network.URI module depends on Parsec which depends on the text
package. This sometimes causes dependency hell.

I would like to propose to split the network package into:
- new network package which contains socket modules only
- network-uri package which contains Network.URI only

Example implementations are available:
	https://github.com/kazu-yamamoto/network/tree/no-uri
	https://github.com/kazu-yamamoto/network-uri

Note that they keep necessary commit history.

In HP, only "HTTP" and "cgi" depends on "network" and they use
"Network.URI". They can be compiled by just adding "network-uri" as
dependency.  Also, "http-conduit" uses "Network.URI". This can also be
compiled by adding "network-uri".

For more information, please refer to:
	https://github.com/haskell/network/issues/76

Discussion period: 2 weeks

--Kazu
(Continue reading)

Michael Snoyman | 8 Jan 07:34 2013

Re: Proposal: splitting the network package




On Tue, Jan 8, 2013 at 8:30 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
Hello,

The network package contains both socket modules and a URI
module. They are in different level. Since new features are actively
added to the socket modules, we may want to install a new network
package even though Haskell Platform includes it. However, the
Network.URI module depends on Parsec which depends on the text
package. This sometimes causes dependency hell.

I would like to propose to split the network package into:
- new network package which contains socket modules only
- network-uri package which contains Network.URI only

Example implementations are available:
        https://github.com/kazu-yamamoto/network/tree/no-uri
        https://github.com/kazu-yamamoto/network-uri

Note that they keep necessary commit history.

In HP, only "HTTP" and "cgi" depends on "network" and they use
"Network.URI". They can be compiled by just adding "network-uri" as
dependency.  Also, "http-conduit" uses "Network.URI". This can also be
compiled by adding "network-uri".

For more information, please refer to:
        https://github.com/haskell/network/issues/76

Discussion period: 2 weeks

--Kazu

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries

+1. When doing testing on Windows, I've run into this dependency hell multiple times, and the ultimate solution was just to remove a number of HP packages from the global database.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Conrad Parker | 8 Jan 07:44 2013

Re: Proposal: splitting the network package

On 8 January 2013 14:30, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Hello,
>
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
>
> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only
>
> Example implementations are available:
>         https://github.com/kazu-yamamoto/network/tree/no-uri
>         https://github.com/kazu-yamamoto/network-uri
>
> Note that they keep necessary commit history.
>
> In HP, only "HTTP" and "cgi" depends on "network" and they use
> "Network.URI". They can be compiled by just adding "network-uri" as
> dependency.  Also, "http-conduit" uses "Network.URI". This can also be
> compiled by adding "network-uri".
>
> For more information, please refer to:
>         https://github.com/haskell/network/issues/76
>
> Discussion period: 2 weeks

+1

Conrad.
Vincent Hanquez | 8 Jan 07:55 2013

Re: Proposal: splitting the network package

On 01/08/2013 06:30 AM, Kazu Yamamoto (山本和彦) wrote:
> Hello,
>
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
+1

--

-- 
Vincent

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Henning Thielemann | 8 Jan 10:02 2013
Picon

Re: Proposal: splitting the network package


On Tue, 8 Jan 2013, Kazu Yamamoto (山本和彦) wrote:

> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only

Splitting the package sounds like a good idea. How about the simpler 
package name "uri"?
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Kazu Yamamoto | 8 Jan 10:07 2013
Picon

Re: Proposal: splitting the network package

> Splitting the package sounds like a good idea. How about the simpler
> package name "uri"?

Unfortunately, "uri" is already registered on Hackage.

--Kazu
Joachim Breitner | 9 Jan 12:47 2013
Picon

Re: Proposal: splitting the network package

Hi,

Am Dienstag, den 08.01.2013, 18:07 +0900 schrieb Kazu Yamamoto:
> > Splitting the package sounds like a good idea. How about the simpler
> > package name "uri"?
> 
> Unfortunately, "uri" is already registered on Hackage.

in the interest of package name sanity we could add Network.URI to the
uri package and use that as the base for network. Would be less
confusing to users to have only one “something-uri” package.

Greetings,
Joachim

--

-- 
Joachim "nomeata" Breitner
  mail <at> joachim-breitner.de  |  nomeata <at> debian.org  |  GPG: 0x4743206C
  xmpp: nomeata <at> joachim-breitner.de | http://www.joachim-breitner.de/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Conrad Parker | 9 Jan 13:17 2013

Re: Proposal: splitting the network package

On 9 January 2013 19:47, Joachim Breitner <mail <at> joachim-breitner.de> wrote:
> Hi,
>
> Am Dienstag, den 08.01.2013, 18:07 +0900 schrieb Kazu Yamamoto:
>> > Splitting the package sounds like a good idea. How about the simpler
>> > package name "uri"?
>>
>> Unfortunately, "uri" is already registered on Hackage.
>
> in the interest of package name sanity we could add Network.URI to the
> uri package and use that as the base for network. Would be less
> confusing to users to have only one “something-uri” package.

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).

Conrad.
Kazu Yamamoto | 9 Jan 13:23 2013
Picon

Re: Proposal: splitting the network package

> 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.).

Also the uri package depends on the utf8-string package. Since
Network.URI is used in cabal-install, this extra dependency may make
bootstrapping harder.

> 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).

Does anybody know Voker57 and/or JaroslavGridin?

--Kazu
Kazu Yamamoto | 10 Jan 04:19 2013
Picon

Re: Proposal: splitting the network package

>> 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).
> 
> Does anybody know Voker57 and/or JaroslavGridin?

I would like to send a massage to Voker57 and JaroslavGridin. But I
don't know JaroslavGridin's e-mail address. Google did not give me an
answer. How can I know it?

--Kazu
Ivan Lazar Miljenovic | 10 Jan 04:56 2013
Picon

Re: Proposal: splitting the network package

On 10 January 2013 13:19, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
>>> 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).
>>
>> Does anybody know Voker57 and/or JaroslavGridin?
>
> I would like to send a massage to Voker57 and JaroslavGridin. But I
> don't know JaroslavGridin's e-mail address. Google did not give me an
> answer. How can I know it?

They're one and the same: http://bitcheese.net/wiki/Voker57/cv (modulo
Anglicisation of Slavic names).

>
> --Kazu
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic <at> gmail.com
http://IvanMiljenovic.wordpress.com
Kazu Yamamoto | 10 Jan 08:33 2013
Picon

Re: Proposal: splitting the network package

> They're one and the same: http://bitcheese.net/wiki/Voker57/cv (modulo
> Anglicisation of Slavic names).

Thanks. I will contact to him to ask the possibility.

--Kazu
Kazu Yamamoto | 12 Jan 13:08 2013
Picon

Re: Proposal: splitting the network package

> Thanks. I will contact to him to ask the possibility.

Yaroslav Gridin said to me that "I'd rather not rename my package".

--Kazu
Kazu Yamamoto | 17 Jan 02:44 2013
Picon

Re: Proposal: splitting the network package

Hello,

If I did not miss messages, many in favor of this proposal and no
against. So, I think we reached clear consensus on splitting the
network package.

One problem is naming. The author of the "uri" package dislikes to
rename it (to cgi-uri for example). 

So, I would like to take "network-uri" as I originally proposed.
What do you guys think?

--Kazu

>> Thanks. I will contact to him to ask the possibility.
> 
> Yaroslav Gridin said to me that "I'd rather not rename my package".
> 
> --Kazu
> 
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 17 Jan 02:50 2013
Picon

Re: Proposal: splitting the network package

On Wed, Jan 16, 2013 at 5:44 PM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Hello,
>
> If I did not miss messages, many in favor of this proposal and no
> against. So, I think we reached clear consensus on splitting the
> network package.
>
> One problem is naming. The author of the "uri" package dislikes to
> rename it (to cgi-uri for example).
>
> So, I would like to take "network-uri" as I originally proposed.
> What do you guys think?

I think it's good enough.
Oliver Charles | 17 Jan 08:25 2013
Picon

Re: Proposal: splitting the network package

On 01/17/2013 01:50 AM, Johan Tibell wrote:
> On Wed, Jan 16, 2013 at 5:44 PM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
>> Hello,
>>
>> If I did not miss messages, many in favor of this proposal and no
>> against. So, I think we reached clear consensus on splitting the
>> network package.
>>
>> One problem is naming. The author of the "uri" package dislikes to
>> rename it (to cgi-uri for example).
>>
>> So, I would like to take "network-uri" as I originally proposed.
>> What do you guys think?
> I think it's good enough.
I don't think it will win us any friends, but I think we should really 
consider if we're willing to do this. A big feature of the platform for 
me is intuitive discovery, and while having it listed in the platform is 
certainly a big pointer, clear naming also makes a big difference.

I'd still like to see the platform consider whether or not we can say 
"overruled" to the original author. Might not win me any friends, but it 
seems Network.URI is more expressive than Text.URI, and thus deserves 
that library name more.

- Ollie
Henning Thielemann | 9 Jan 13:54 2013
Picon

Re: Proposal: splitting the network package


On Wed, 9 Jan 2013, Conrad Parker wrote:

> 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).

... or rename uri package to something else (maybe uri-cgi) and rename 
network-uri to uri.
Joachim Breitner | 9 Jan 14:24 2013
Picon

Re: Proposal: splitting the network package

Hi,

Am Mittwoch, den 09.01.2013, 20:17 +0800 schrieb Conrad Parker:
> 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).

sounds also fine. According to
http://packdeps.haskellers.com/reverse/uri
this would break

      * github which, in violation of PVP has no upper bound on the uri
        version, and hence cannot complain about builds failing
      * hellnet, same
      * trajectory, same
      * isohunt, which is safe due to a <0.2 version constraint
      * an unknown quantify of private non-hackaged code

So it seems the impact of a non-compatible upload to uri would be low.

The question is more likely: Do maintainers have a strong ownership of
names they claim on hackage, or do we liberally take over names when it
is for the greater good? In Debian, such a name-take-over would be
highly controversial, but I’m not saying that this is a good thing.

Greetings,
Joachim

--

-- 
Joachim "nomeata" Breitner
  mail <at> joachim-breitner.de  |  nomeata <at> debian.org  |  GPG: 0x4743206C
  xmpp: nomeata <at> joachim-breitner.de | http://www.joachim-breitner.de/

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Vincent Hanquez | 9 Jan 18:18 2013

Re: Proposal: splitting the network package

On 01/09/2013 01:24 PM, Joachim Breitner wrote:
> So it seems the impact of a non-compatible upload to uri would be low.
>
> The question is more likely: Do maintainers have a strong ownership of
> names they claim on hackage, or do we liberally take over names when it
> is for the greater good? In Debian, such a name-take-over would be
> highly controversial, but I’m not saying that this is a good thing.
>

Personally i would be in favor of taking over a package name provided 
the following:

* provided it's a platform thing.
* it has wide support in the community
* the package name is generic enough
* the amount of breakage is minimal
* the authors / maintainers have been contacted (if way to contact are 
still valid)

Maybe the authors / maintainers of uri could be sympathetic to a 
renaming too.

--

-- 
Vincent
Ian Lynagh | 9 Jan 18:38 2013
Picon

Re: Proposal: splitting the network package

On Wed, Jan 09, 2013 at 05:18:15PM +0000, Vincent Hanquez wrote:
> On 01/09/2013 01:24 PM, Joachim Breitner wrote:
> >So it seems the impact of a non-compatible upload to uri would be low.
> >
> >The question is more likely: Do maintainers have a strong ownership of
> >names they claim on hackage, or do we liberally take over names when it
> >is for the greater good? In Debian, such a name-take-over would be
> >highly controversial, but I’m not saying that this is a good thing.
> >
> 
> Personally i would be in favor of taking over a package name
> provided the following:
> 
> * provided it's a platform thing.
> * it has wide support in the community
> * the package name is generic enough
> * the amount of breakage is minimal
> * the authors / maintainers have been contacted (if way to contact
> are still valid)

I think it would be useful to make and record somewhere a decision about
who has the final say about names of packages on hackage.

My opinion is that "the current user of the name" is a bad choice, given
names are allocated on a first-come first-served basis. My suggestion
would be for the haskell.org committee to ultimately have the final say
(although we'd obviously hope that the parties involved would normally
come to an amicable agreement without having to go that far).

Thanks
Ian

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Graham Klyne | 17 Jan 10:25 2013

Re: Proposal: splitting the network package

On 09/01/2013 17:18, Vincent Hanquez wrote:
> On 01/09/2013 01:24 PM, Joachim Breitner wrote:
>> So it seems the impact of a non-compatible upload to uri would be low.
>>
>> The question is more likely: Do maintainers have a strong ownership of
>> names they claim on hackage, or do we liberally take over names when it
>> is for the greater good? In Debian, such a name-take-over would be
>> highly controversial, but I’m not saying that this is a good thing.
>>
>
> Personally i would be in favor of taking over a package name provided the
> following:
>
> * provided it's a platform thing.
> * it has wide support in the community
> * the package name is generic enough
> * the amount of breakage is minimal
> * the authors / maintainers have been contacted (if way to contact are still valid)
>
> Maybe the authors / maintainers of uri could be sympathetic to a renaming too.
>

As original author and one very sporadic maintainer of Network.URI, I'm 
sympathetic.  But see other message about compatibility issues.

(It occurs to me that if there's a way for a package to "inject" additional 
names into another/existing package, the breakage issues might be avoidable, but 
thjat probably opens a different can of works.)

#g
--
Conrad Parker | 10 Jan 04:04 2013

Re: Proposal: splitting the network package

On 9 January 2013 21:24, Joachim Breitner <mail <at> joachim-breitner.de> wrote:
> According to
> http://packdeps.haskellers.com/reverse/uri
> this would break
>
>       * github which, in violation of PVP has no upper bound on the uri
>         version, and hence cannot complain about builds failing

I was curious about this package, and it turns out it was not actually
using anything from Text.URI anyway; I've sent a pull request to
remove the dependency (a 2-line patch):

https://github.com/mike-burns/github/pull/28

The github package already depends on network (unsurprisingly) and
http-types, the latter of which provides http query string handling.

Conrad.
Graham Klyne | 17 Jan 10:20 2013

Re: Proposal: splitting the network package

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
Gregory Collins | 17 Jan 11:45 2013
Picon

Re: Proposal: splitting the network package

On Thu, Jan 17, 2013 at 10:20 AM, Graham Klyne <GK <at> ninebynine.org> wrote:
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.

I agree. My take on these issues:
  • no, the uri package cannot be "hijacked" by us
  • the URI stuff can and should be moved out of network, but to be done properly it would need to get a deprecation warning for at least one platform cycle. There's been a lot of this breakage-without-warning in the core libraries lately -- directory-1.2 freshest in my mind -- which IMO we should stop and try not to tolerate in the future.
  • the current Network.URI is not a great module to begin with
  • do we need a library to handle URIs in the platform at all? I would argue for its complete removal here. If necessary, after a deprecation cycle we can just throw that code into HTTP. It makes sense for it to live there (do we want to be providing people with APIs that use String these days?), and we don't contribute to package proliferation.
G
--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Graham Klyne | 17 Jan 12:32 2013

Re: Proposal: splitting the network package

On 17/01/2013 10:45, Gregory Collins wrote:
>     - the current Network.URI is not a great module to begin with

This may well be true, but I'd like to understand why you say this.

>     - do we need a library to handle URIs in the platform at all? I would
>     argue for its complete removal here. If necessary, after a deprecation
>     cycle we can just throw that code into HTTP. It makes sense for it to live
>     there (do we want to be providing people with APIs that use String these
>     days?), and we don't contribute to package proliferation.

If Haskell Platform is to be a serious contender for web applications generally, 
I claim it MUST have a good URI implementation.  And URIs are about far more 
than just HTTP, so I think simply treating them as part of HTTP doesn't entirely 
hack it;  they also underpin aspects of XML and linked data applications, 
somewhat independently of HTTP.

#g
--
Gregory Collins | 17 Jan 13:22 2013
Picon

Re: Proposal: splitting the network package

On Thu, Jan 17, 2013 at 12:32 PM, Graham Klyne <GK <at> ninebynine.org> wrote:
If Haskell Platform is to be a serious contender for web applications generally, I claim it MUST have a good URI implementation.  And URIs are about far more than just HTTP, so I think simply treating them as part of HTTP doesn't entirely hack it;  they also underpin aspects of XML and linked data applications, somewhat independently of HTTP.

My point above was: there is not any single implementation of URI that is worthy of canonization, including the existing one in Network.URI, and moving the current code into HTTP (which is already itself pretty weird/nonstandard, and a prime candidate for replacement IMO) would offer a gentle glide path for users of the existing API.

Until someone writes a decent URI library that we can bless, I'd argue that we shouldn't provide anything specifically in the platform.

G
--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Graham Klyne | 17 Jan 13:37 2013

Re: Proposal: splitting the network package

On 17/01/2013 12:22, Gregory Collins wrote:
> On Thu, Jan 17, 2013 at 12:32 PM, Graham Klyne <GK <at> ninebynine.org> wrote:
>
>> If Haskell Platform is to be a serious contender for web applications
>> generally, I claim it MUST have a good URI implementation.  And URIs are
>> about far more than just HTTP, so I think simply treating them as part of
>> HTTP doesn't entirely hack it;  they also underpin aspects of XML and
>> linked data applications, somewhat independently of HTTP.
>
>
> My point above was: there is not any single implementation of URI that is
> worthy of canonization, including the existing one in Network.URI, and
> moving the current code into HTTP (which is already itself pretty
> weird/nonstandard, and a prime candidate for replacement IMO) would offer a
> gentle glide path for users of the existing API.
>
> Until someone writes a decent URI library that we can bless, I'd argue that
> we shouldn't provide anything specifically in the platform.

I don't want to be defensive, but I'd like to know what criteria would be 
satisfied by "a decent URI library that we can bless".

As an implementation of RFC 3986 [1] (the current definitive specification of a 
URI), I believe Network.URI is fairly complete.  I'm sure there are aspects that 
might be considered poor style, poorly implemented, lacking some useful 
functions, or poor API design, but nobody's really said what they are (*).  And 
I'd suggest that all but the final one of those criteria are fixable in an 
existing library.

(*) actually, that's not completely true, there are some long-outstanding 
requests with respect to URI-escaping support and handling of internationalized 
URIs (i.e. IRIs), but these are over and above what is specified by RFC 3986, 
and could be added compatibly to an existing library.

#g
--

[1] http://tools.ietf.org/html/rfc3986
Gregory Collins | 17 Jan 16:51 2013
Picon

Re: Proposal: splitting the network package


On Thu, Jan 17, 2013 at 1:37 PM, Graham Klyne <GK <at> ninebynine.org> wrote:
I don't want to be defensive, but I'd like to know what criteria would be satisfied by "a decent URI library that we can bless".

Network.URI is well-written, has a (mostly) acceptable API, and has tests, but facts on the ground have changed since you wrote this module in 2004. These days, the use of String in text-processing code is pretty close to disqualifying IMO. My criteria for a "decent URI library that we can bless" would be:

  * datatypes and primitive functions using ByteString and/or Text, with parsing and rendering functions working both on Text and on utf-8-encoded ByteStrings

  * a faster parser. I just plugged Network.URI's parser into criterion and got a timing of 12µs to parse a 52-character URI. Switching the benchmark to use a 365-character URI causes the time to balloon to 85µs. That's looking pretty linear at roughly 4MB/s throughput. As a data point, on the same machine my work-in-progress Snap branch based on io-streams can parse a 365-byte HTTP request in 1.8µs (about 190 MB/s), and that's running through a bunch of streaming IO gunk.

As an implementation of RFC 3986 [1] (the current definitive specification of a URI), I believe Network.URI is fairly complete.  I'm sure there are aspects that might be considered poor style, poorly implemented, lacking some useful functions, or poor API design, but nobody's really said what they are (*).  And I'd suggest that all but the final one of those criteria are fixable in an existing library.

Fixable yes, fixed by anyone yet? no. Michael's uri-conduit has the "correct" types, but that library is under-documented, incomplete compared to Network.URI, and there's no way the canonical URI library should be depending on conduit.

G
--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Conrad Parker | 17 Jan 17:38 2013

Re: Proposal: splitting the network package

On 17 January 2013 23:51, Gregory Collins <greg <at> gregorycollins.net> wrote:
>
> On Thu, Jan 17, 2013 at 1:37 PM, Graham Klyne <GK <at> ninebynine.org> wrote:
>>
>> I don't want to be defensive, but I'd like to know what criteria would be
>> satisfied by "a decent URI library that we can bless".
>
>
> Network.URI is well-written, has a (mostly) acceptable API, and has tests,
> but facts on the ground have changed since you wrote this module in 2004.
> These days, the use of String in text-processing code is pretty close to
> disqualifying IMO. My criteria for a "decent URI library that we can bless"
> would be:
>
>   * datatypes and primitive functions using ByteString and/or Text, with
> parsing and rendering functions working both on Text and on utf-8-encoded
> ByteStrings
>
>   * a faster parser. I just plugged Network.URI's parser into criterion and
> got a timing of 12µs to parse a 52-character URI. Switching the benchmark to
> use a 365-character URI causes the time to balloon to 85µs. That's looking
> pretty linear at roughly 4MB/s throughput. As a data point, on the same
> machine my work-in-progress Snap branch based on io-streams can parse a
> 365-byte HTTP request in 1.8µs (about 190 MB/s), and that's running through
> a bunch of streaming IO gunk.
>
>> As an implementation of RFC 3986 [1] (the current definitive specification
>> of a URI), I believe Network.URI is fairly complete.  I'm sure there are
>> aspects that might be considered poor style, poorly implemented, lacking
>> some useful functions, or poor API design, but nobody's really said what
>> they are (*).  And I'd suggest that all but the final one of those criteria
>> are fixable in an existing library.
>
>
> Fixable yes, fixed by anyone yet? no. Michael's uri-conduit has the
> "correct" types, but that library is under-documented, incomplete compared
> to Network.URI, and there's no way the canonical URI library should be
> depending on conduit.

c'mon, it's not like anyone needs to go parsing billions of URIs in a hurry.

But seriously, Graham's URI module was one of the things that
convinced me about Haskell in the first place: that the libraries are
so well-written that they are the reference implementation of a
standard. Browsing the docs for Network.URI and the time library
really convinced me that people in Haskell land care about doing
things correctly.

Sure, someone should write a faster version with more fashionable
types, but I'd really view that as an incremental improvement.

Conrad.
Bryan O'Sullivan | 17 Jan 17:50 2013

Re: Proposal: splitting the network package

On Thu, Jan 17, 2013 at 8:38 AM, Conrad Parker <conrad <at> metadecks.org> wrote:
> c'mon, it's not like anyone needs to go parsing billions of URIs in a hurry.

This is not even a bit true, I'm afraid. I have run into innumerable
cases where libraries low in some language's stack, but on a hot code
path, were slow enough to dramatically affect both latency and
throughput. The URI handling code in network would be a prime instance
of that.
Conrad Parker | 17 Jan 23:15 2013

Re: Proposal: splitting the network package

On 18 January 2013 00:50, Bryan O'Sullivan <bos <at> serpentine.com> wrote:
> On Thu, Jan 17, 2013 at 8:38 AM, Conrad Parker <conrad <at> metadecks.org> wrote:
>> c'mon, it's not like anyone needs to go parsing billions of URIs in a hurry.
>
> This is not even a bit true, I'm afraid. I have run into innumerable
> cases where libraries low in some language's stack, but on a hot code
> path, were slow enough to dramatically affect both latency and
> throughput. The URI handling code in network would be a prime instance
> of that.

Indeed. I was being a little bit facetious: the problem of parsing
billions of URIs comes up fairly often in web crawling.

Conrad.
Jeremy Shaw | 17 Jan 18:01 2013

Re: Proposal: splitting the network package

On Thu, Jan 17, 2013 at 5:32 AM, Graham Klyne <GK <at> ninebynine.org> wrote:
> On 17/01/2013 10:45, Gregory Collins wrote:
>>
>>     - the current Network.URI is not a great module to begin with
>
>
> This may well be true, but I'd like to understand why you say this.

Network.URI is better now that it exposed the record constructors. But
I have never been too happy by the Show instance -- and the 'missing'
Read instance. Also.. it doesn't seem to provide much in the way of
constructing URIs aside from parsing already constructed ones. Now
that the constructors are exposed.. it is a bit easier. But the fact
that (for example) the port number has to include the : makes it
trickier to use.

And, of course, Text would be nice.

- jeremy
wren ng thornton | 21 Jan 05:52 2013

Re: Proposal: splitting the network package

On 1/17/13 6:32 AM, Graham Klyne wrote:
> If Haskell Platform is to be a serious contender for web applications
> generally, I claim it MUST have a good URI implementation.  And URIs are
> about far more than just HTTP, so I think simply treating them as part
> of HTTP doesn't entirely hack it;  they also underpin aspects of XML and
> linked data applications, somewhat independently of HTTP.

+1. There are plenty of projects and tools I can think of that would 
want to use URIs without having any reason to bring in all of HTTP.

--

-- 
Live well,
~wren
Gregory Collins | 21 Jan 11:54 2013
Picon

Re: Proposal: splitting the network package

On Mon, Jan 21, 2013 at 5:52 AM, wren ng thornton <wren <at> freegeek.org> wrote:
+1. There are plenty of projects and tools I can think of that would want to use URIs without having any reason to bring in all of HTTP.

The reason I proposed that doesn't have anything to do with whether it makes sense for the URI code to live in that package in the long term. Instead:
  • HTTP is also already in the platform
  • HTTP uses this code
  • the existing Network.URI code is inefficient by design and cannot be improved without breaking user code
  • for backwards compatibility, we would like to have this code live on somewhere so that porting old code is easier.
G
--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Ben Millwood | 21 Jan 12:51 2013
Picon

Re: Proposal: splitting the network package

On Mon, Jan 21, 2013 at 11:54:44AM +0100, Gregory Collins wrote:
>   - the existing Network.URI code is inefficient by design and cannot be
>   improved without breaking user code

It also cannot be improved without finding someone willing to improve 
it. I suspect that's going to be the bigger obstacle in practice, and we 
should wait until we have a replacement before dismissing the original 
(see also: old-locale).
Kazu Yamamoto | 31 Jan 10:41 2013
Picon

Re: Proposal: splitting the network package

Hi,

>   * the URI stuff can and should be moved out of network, but to be done
>     properly it would need to get a deprecation warning for at least one
>     platform cycle. There's been a lot of this breakage-without-warning in the
>     core libraries lately -- directory-1.2 freshest in my mind -- which IMO we
>     should stop and try not to tolerate in the future.

How about this plan?

Right now:

- Register the "network-uri" package which includes Network.URI to
  Hackage.
- Put the DEPRECATED pragma to Network.URI of "network", suggesting
  usage of "network-uri". And upload "network" to Hackage.
- Ask the authors of "HTTP" and "cgi" to use network-uri
- Ask the HP maintainers to include new "network", "network-uri",
  "HTTP" and "cgi".

After the next HP is released:
- Remove Network.URI from "network" and upload to Hackage.
- Ask the HP maintainers to include new "network"

Anytime:
- Add fast URI modules such as Network.URI to "network-uri" if
  necessary.

--Kazu
Thomas Schilling | 31 Jan 11:16 2013

Re: Proposal: splitting the network package

On 31 January 2013 09:41, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> - Register the "network-uri" package which includes Network.URI to
>   Hackage.
> - Put the DEPRECATED pragma to Network.URI of "network", suggesting
>   usage of "network-uri". And upload "network" to Hackage.

I don't think this would work. If "network" still contains a module
Network.URI and a package adds a dependency on "network-uri" which
also exports a module Network.URI, then you would have to specify the
package name in your import, i.e.:

  import "network-uri" Network.URI

Then, once Network.URI is removed from "network", users have to edit
their sources again to remove the explicit package import. I think the
only reasonable way to handle things is to use flags in a .cabal file,
i.e., the same way we had to deal with base-3 => base-4 transition
(which was very annoying).
Henning Thielemann | 31 Jan 11:28 2013
Picon

Re: Proposal: splitting the network package


On Thu, 31 Jan 2013, Thomas Schilling wrote:

> I don't think this would work. If "network" still contains a module
> Network.URI and a package adds a dependency on "network-uri" which
> also exports a module Network.URI, then you would have to specify the
> package name in your import, i.e.:
>
>  import "network-uri" Network.URI
>
> Then, once Network.URI is removed from "network", users have to edit
> their sources again to remove the explicit package import. I think the
> only reasonable way to handle things is to use flags in a .cabal file,
> i.e., the same way we had to deal with base-3 => base-4 transition
> (which was very annoying).

An alternative would be to split the "network" package into "network-uri" 
and "network-socket". Users of network-uri would have to switch to 
network-socket as well. However, the types of "network" and 
"network-socket" would be incompatible unless the "network-socket" package 
re-exports the modules from "network" or vice versa.

E.g. could we put this into the "network" package:

{-# LANGUAGE PackageImports #-}
module Network.Socket ( module S )  where

import qualified "network-socket" Network.Socket as S

?

Interestingly, the GHC documentation uses Network.Socket for explaining 
the PackageImports extension.
Michael Snoyman | 31 Jan 13:22 2013

Re: Proposal: splitting the network package




On Thu, Jan 31, 2013 at 12:28 PM, Henning Thielemann <lemming <at> henning-thielemann.de> wrote:

On Thu, 31 Jan 2013, Thomas Schilling wrote:

I don't think this would work. If "network" still contains a module
Network.URI and a package adds a dependency on "network-uri" which
also exports a module Network.URI, then you would have to specify the
package name in your import, i.e.:

 import "network-uri" Network.URI

Then, once Network.URI is removed from "network", users have to edit
their sources again to remove the explicit package import. I think the
only reasonable way to handle things is to use flags in a .cabal file,
i.e., the same way we had to deal with base-3 => base-4 transition
(which was very annoying).

An alternative would be to split the "network" package into "network-uri" and "network-socket". Users of network-uri would have to switch to network-socket as well. However, the types of "network" and "network-socket" would be incompatible unless the "network-socket" package re-exports the modules from "network" or vice versa.

E.g. could we put this into the "network" package:

{-# LANGUAGE PackageImports #-}
module Network.Socket ( module S )  where

import qualified "network-socket" Network.Socket as S

?

Interestingly, the GHC documentation uses Network.Socket for explaining the PackageImports extension.


_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


Recently, we have a similar situation with http-conduit. Based on that, I'd recommend going for a conditional export situation.

* Release a new version of network (1.5) that does not include the Network.URI module.
* Create a network-uri package that uses conditionals in the cabal file.
    * If it's compiled against network version 1.4 or earlier, it doesn't provide any modules.
    * If it's compiled against network 1.5 or later, it provides the Network.URI module.

This way, there's only ever one package which is providing Network.URI.

Note: I think there might be a requirement that a library section always have at least one exported module. If so, I suppose network-uri should always export some extra package as well, perhaps Network.URI.Temp which contains everything in Network.URI.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Herbert Valerio Riedel | 31 Jan 14:28 2013
Picon

Re: Proposal: splitting the network package

Michael Snoyman <michael <at> snoyman.com> writes:

[...]

> * Release a new version of network (1.5) that does not include the
> Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

Alas, this causes some of the conditional-API issues mentioned in [1],
specifically the following situation:

Say, I have a package which specifies only its dependancy on
'network-uri' (but not 'network') for its 'Network.URI' module, then the
package compilation breaks depending on the actual version of the
'network' package linked against.

 [1]: http://www.haskell.org/pipermail/libraries/2012-November/018750.html
Michael Snoyman | 31 Jan 15:01 2013

Re: Proposal: splitting the network package




On Thu, Jan 31, 2013 at 3:28 PM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
Michael Snoyman <michael <at> snoyman.com> writes:


[...]

> * Release a new version of network (1.5) that does not include the
> Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

Alas, this causes some of the conditional-API issues mentioned in [1],
specifically the following situation:

Say, I have a package which specifies only its dependancy on
'network-uri' (but not 'network') for its 'Network.URI' module, then the
package compilation breaks depending on the actual version of the
'network' package linked against.



 [1]: http://www.haskell.org/pipermail/libraries/2012-November/018750.html


That's true, but I don't think we have *any* means at our disposal of creating a migration plan that has zero impact on users. The reason I suggested my approach is that the only change users would need to make is to add network-uri to their dependency list. You're correct that it's possible that a user could depend exclusively on network-uri and thereby cause trouble for users of the older network package, but I would argue that's an acceptable tradeoff in this case.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Kazu Yamamoto | 1 Feb 06:53 2013
Picon

Re: Proposal: splitting the network package

> * Release a new version of network (1.5) that does not include the Network.URI
> module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.

I don't understand benefits of this plan. Consider another simpler
plan: we just provide two packages:
  - "network" without Network.URI
  - "network-uri" which includes Network.URI only (without the
    conditionals)

What is the difference Michael's one and this?

In other words, what does Michael's one contribute from the backward
compatibility point of view?

--Kazu
Michael Snoyman | 1 Feb 07:05 2013

Re: Proposal: splitting the network package




On Fri, Feb 1, 2013 at 7:53 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> * Release a new version of network (1.5) that does not include the Network.URI
> module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
> provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
> Network.URI module.

I don't understand benefits of this plan. Consider another simpler
plan: we just provide two packages:
  - "network" without Network.URI
  - "network-uri" which includes Network.URI only (without the
    conditionals)

What is the difference Michael's one and this?

In other words, what does Michael's one contribute from the backward
compatibility point of view?

--Kazu

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries


Many users won't be able to upgrade to the new network library immediately. However, adding an extra dependency on (an essentially empty) network-uri is perfectly feasible. My approach makes it possible for library authors to make their code compatible with both network 1.4 and 1.5 with just a single line change.

If you want to see examples that were more painful from the author perspective, consider the previous merging of network and network-bytestring, or the blaze-markup/blaze-html split. Both of them required adding cabal flags and conditionals to every user package that wanted to work with both versions, which definitely caused some headaches.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Johan Tibell | 4 Feb 23:40 2013
Picon

Re: Proposal: splitting the network package

On Thu, Jan 31, 2013 at 10:05 PM, Michael Snoyman <michael <at> snoyman.com> wrote:

Many users won't be able to upgrade to the new network library immediately. However, adding an extra dependency on (an essentially empty) network-uri is perfectly feasible. My approach makes it possible for library authors to make their code compatible with both network 1.4 and 1.5 with just a single line change.

If you want to see examples that were more painful from the author perspective, consider the previous merging of network and network-bytestring, or the blaze-markup/blaze-html split. Both of them required adding cabal flags and conditionals to every user package that wanted to work with both versions, which definitely caused some headaches.

Someone ought to write a "How to split a package" and a "How to merge two packages" guide that carefully lists out the steps and the pros and cons of the approach.

-- Johan
 
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Michael Snoyman | 5 Feb 06:28 2013

Re: Proposal: splitting the network package




On Tue, Feb 5, 2013 at 12:40 AM, Johan Tibell <johan.tibell <at> gmail.com> wrote:
On Thu, Jan 31, 2013 at 10:05 PM, Michael Snoyman <michael <at> snoyman.com> wrote:
Many users won't be able to upgrade to the new network library immediately. However, adding an extra dependency on (an essentially empty) network-uri is perfectly feasible. My approach makes it possible for library authors to make their code compatible with both network 1.4 and 1.5 with just a single line change.

If you want to see examples that were more painful from the author perspective, consider the previous merging of network and network-bytestring, or the blaze-markup/blaze-html split. Both of them required adding cabal flags and conditionals to every user package that wanted to work with both versions, which definitely caused some headaches.

Someone ought to write a "How to split a package" and a "How to merge two packages" guide that carefully lists out the steps and the pros and cons of the approach.

-- Johan
 

I'll be happy to write such a guide. But I'd like to get some consensus on whether the approach I've sketched out so far is acceptable, particular for packages in the HP.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Kazu Yamamoto | 6 Feb 07:08 2013
Picon

Re: Proposal: splitting the network package

> I'll be happy to write such a guide. But I'd like to get some consensus on
> whether the approach I've sketched out so far is acceptable, particular for
> packages in the HP.

I support your approach.

--Kazu
Herbert Valerio Riedel | 6 Feb 10:22 2013
Picon

Re: Proposal: splitting the network package

Michael Snoyman <michael <at> snoyman.com> writes:

[...]

>> An alternative would be to split the "network" package into
>> "network-uri" and "network-socket". Users of network-uri would have
>> to switch to network-socket as well. However, the types of "network"
>> and "network-socket" would be incompatible unless the
>> "network-socket" package re-exports the modules from "network" or
>> vice versa.
>>
>> E.g. could we put this into the "network" package:
>>
>> {-# LANGUAGE PackageImports #-}
>> module Network.Socket ( module S )  where
>>
>> import qualified "network-socket" Network.Socket as S
>>
>> ?

[...]

> Recently, we have a similar situation with http-conduit. Based on that, I'd
> recommend going for a conditional export situation.
>
> * Release a new version of network (1.5) that does not include the
>   Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
>       provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
>       Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

[...]

What's the actual downside with Henning's proposed package splitting
method?

I.e., the new transitional `network` package wouldn't have any visible
changes in its exports (and so wouldn't require any major version bump),
but its (re-exported) implementation gets moved into two new packages,
`network-uri` and `network-socket`.

So users of `network` which don't want to or can't switch yet to the new
`network-{uri,socket}` packages can remain on `network` for the time
being.

After an appropriate deprecation cycle, the `network` packages doesn't
get updated anymore to support newer major package versions of
`network-{uri,socket}` which may then start to break compatibility
significantly at the type-level.

To me, this seems to avoid breaking the PVP contract, as well as
avoiding requiring clients of `network` to introduce
conditional-compilation directives. Moreover, it wouldn't require client
packages to switch to new packages right away, while sharing the data
types of the new `network-{socket,uri}` packages.

Am I overlooking something?

cheers,
  hvr
Michael Snoyman | 6 Feb 18:49 2013

Re: Proposal: splitting the network package




On Wed, Feb 6, 2013 at 11:22 AM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
Michael Snoyman <michael <at> snoyman.com> writes:

[...]

>> An alternative would be to split the "network" package into
>> "network-uri" and "network-socket". Users of network-uri would have
>> to switch to network-socket as well. However, the types of "network"
>> and "network-socket" would be incompatible unless the
>> "network-socket" package re-exports the modules from "network" or
>> vice versa.
>>
>> E.g. could we put this into the "network" package:
>>
>> {-# LANGUAGE PackageImports #-}
>> module Network.Socket ( module S )  where
>>
>> import qualified "network-socket" Network.Socket as S
>>
>> ?

[...]

> Recently, we have a similar situation with http-conduit. Based on that, I'd
> recommend going for a conditional export situation.
>
> * Release a new version of network (1.5) that does not include the
>   Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
>       provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
>       Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

[...]

What's the actual downside with Henning's proposed package splitting
method?

I.e., the new transitional `network` package wouldn't have any visible
changes in its exports (and so wouldn't require any major version bump),
but its (re-exported) implementation gets moved into two new packages,
`network-uri` and `network-socket`.

So users of `network` which don't want to or can't switch yet to the new
`network-{uri,socket}` packages can remain on `network` for the time
being.

After an appropriate deprecation cycle, the `network` packages doesn't
get updated anymore to support newer major package versions of
`network-{uri,socket}` which may then start to break compatibility
significantly at the type-level.

To me, this seems to avoid breaking the PVP contract, as well as
avoiding requiring clients of `network` to introduce
conditional-compilation directives. Moreover, it wouldn't require client
packages to switch to new packages right away, while sharing the data
types of the new `network-{socket,uri}` packages.

Am I overlooking something?

cheers,
  hvr

Well, that approach requires the creation of an extra package and ultimately deprecating the main package, forcing users to have to learn about a new package. I'd rather not have to rename a package just because I want to split off one piece of functionality to a separate package.

Michael
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Gregory Collins | 6 Feb 20:22 2013
Picon

Re: Proposal: splitting the network package

Also "network" is where we want the network stuff to live, not "network-socket".


On Wed, Feb 6, 2013 at 5:49 PM, Michael Snoyman <michael <at> snoyman.com> wrote:



On Wed, Feb 6, 2013 at 11:22 AM, Herbert Valerio Riedel <hvr <at> gnu.org> wrote:
Michael Snoyman <michael <at> snoyman.com> writes:

[...]

>> An alternative would be to split the "network" package into
>> "network-uri" and "network-socket". Users of network-uri would have
>> to switch to network-socket as well. However, the types of "network"
>> and "network-socket" would be incompatible unless the
>> "network-socket" package re-exports the modules from "network" or
>> vice versa.
>>
>> E.g. could we put this into the "network" package:
>>
>> {-# LANGUAGE PackageImports #-}
>> module Network.Socket ( module S )  where
>>
>> import qualified "network-socket" Network.Socket as S
>>
>> ?

[...]

> Recently, we have a similar situation with http-conduit. Based on that, I'd
> recommend going for a conditional export situation.
>
> * Release a new version of network (1.5) that does not include the
>   Network.URI module.
> * Create a network-uri package that uses conditionals in the cabal file.
>     * If it's compiled against network version 1.4 or earlier, it doesn't
>       provide any modules.
>     * If it's compiled against network 1.5 or later, it provides the
>       Network.URI module.
>
> This way, there's only ever one package which is providing Network.URI.

[...]

What's the actual downside with Henning's proposed package splitting
method?

I.e., the new transitional `network` package wouldn't have any visible
changes in its exports (and so wouldn't require any major version bump),
but its (re-exported) implementation gets moved into two new packages,
`network-uri` and `network-socket`.

So users of `network` which don't want to or can't switch yet to the new
`network-{uri,socket}` packages can remain on `network` for the time
being.

After an appropriate deprecation cycle, the `network` packages doesn't
get updated anymore to support newer major package versions of
`network-{uri,socket}` which may then start to break compatibility
significantly at the type-level.

To me, this seems to avoid breaking the PVP contract, as well as
avoiding requiring clients of `network` to introduce
conditional-compilation directives. Moreover, it wouldn't require client
packages to switch to new packages right away, while sharing the data
types of the new `network-{socket,uri}` packages.

Am I overlooking something?

cheers,
  hvr

Well, that approach requires the creation of an extra package and ultimately deprecating the main package, forcing users to have to learn about a new package. I'd rather not have to rename a package just because I want to split off one piece of functionality to a separate package.

Michael

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries




--
Gregory Collins <greg <at> gregorycollins.net>
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Kazu Yamamoto | 8 Feb 07:40 2013
Picon

Re: Proposal: splitting the network package

> Well, that approach requires the creation of an extra package and ultimately
> deprecating the main package, forcing users to have to learn about a new
> package. I'd rather not have to rename a package just because I want to split
> off one piece of functionality to a separate package.

I think that Michael should write two approaches in the document.
And we should choose one out of two for "network".

--Kazu
Michael Snoyman | 8 Feb 14:33 2013

Re: Proposal: splitting the network package




On Fri, Feb 8, 2013 at 8:40 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Well, that approach requires the creation of an extra package and ultimately
> deprecating the main package, forcing users to have to learn about a new
> package. I'd rather not have to rename a package just because I want to split
> off one piece of functionality to a separate package.

I think that Michael should write two approaches in the document.
And we should choose one out of two for "network".


I've written up the approach I advocated and put it in a Google document[1] for comments. I'd rather not volunteer to write up an explanation of someone else's approach, as I might guess some of the details wrong.

Note that my stated objectives (particularly 5) may go beyond what we'd previously been discussing here, but they all came up in my work on http-conduit/http-conduit-browser, so I think it likely that the need will resurface for someone else in the future.

I'll be back online on Sunday to review comments and to add the second half on merge strategies (which admittedly I have not thought about quite as much). If there's consensus with the document, I can move it to the Haskell Wiki, or wherever else someone thinks would be more logical.

Michael

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Michael Snoyman | 10 Feb 06:19 2013

Re: Proposal: splitting the network package




On Fri, Feb 8, 2013 at 3:33 PM, Michael Snoyman <michael <at> snoyman.com> wrote:



On Fri, Feb 8, 2013 at 8:40 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Well, that approach requires the creation of an extra package and ultimately
> deprecating the main package, forcing users to have to learn about a new
> package. I'd rather not have to rename a package just because I want to split
> off one piece of functionality to a separate package.

I think that Michael should write two approaches in the document.
And we should choose one out of two for "network".


I've written up the approach I advocated and put it in a Google document[1] for comments. I'd rather not volunteer to write up an explanation of someone else's approach, as I might guess some of the details wrong.

Note that my stated objectives (particularly 5) may go beyond what we'd previously been discussing here, but they all came up in my work on http-conduit/http-conduit-browser, so I think it likely that the need will resurface for someone else in the future.

I'll be back online on Sunday to review comments and to add the second half on merge strategies (which admittedly I have not thought about quite as much). If there's consensus with the document, I can move it to the Haskell Wiki, or wherever else someone thinks would be more logical.

Michael



I've also added a section on merging.
_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Simon Marlow | 23 Jan 14:01 2013
Picon

Re: Proposal: splitting the network package

On 17/01/13 09:20, Graham Klyne wrote:

> FWIW, when I originally implemented URI, the interface was based on an
> existing package, but I don't recall exactly which.

It was based on the previous Network.URI, by me :-) (just FYI)

Cheers,
	Simon
Christian Maeder | 17 Jan 18:04 2013
Picon

Re: Proposal: splitting the network package

Am 08.01.2013 10:07, schrieb Kazu Yamamoto (山本和彦):
>> Splitting the package sounds like a good idea. How about the simpler
>> package name "uri"?
>
> Unfortunately, "uri" is already registered on Hackage.

Maybe URIs could be generalized to IRIs?

I think "iri" is not yet registered on Hackage.

Cheers Christian

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Milan Straka | 8 Jan 10:14 2013
Picon

Re: Proposal: splitting the network package

> -----Original message-----
> From: Kazu Yamamoto <kazu <at> iij.ad.jp>
> Sent: 8 Jan 2013, 15:30
>
> Hello,
> 
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
> 
> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only
> 
> Example implementations are available:
> 	https://github.com/kazu-yamamoto/network/tree/no-uri
> 	https://github.com/kazu-yamamoto/network-uri
> 
> Note that they keep necessary commit history.
> 
> In HP, only "HTTP" and "cgi" depends on "network" and they use
> "Network.URI". They can be compiled by just adding "network-uri" as
> dependency.  Also, "http-conduit" uses "Network.URI". This can also be
> compiled by adding "network-uri".
> 
> For more information, please refer to:
> 	https://github.com/haskell/network/issues/76

+1

Cheers,
Milan Straka
Erik Hesselink | 8 Jan 10:26 2013
Picon

Re: Proposal: splitting the network package

+1. I've also had some trouble installing newer versions of network
due to the parsec dependency. Packages seem to be very particular
about which version of parsec they want.

Regards,

Erik

On Tue, Jan 8, 2013 at 7:30 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Hello,
>
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
>
> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only
>
> Example implementations are available:
>         https://github.com/kazu-yamamoto/network/tree/no-uri
>         https://github.com/kazu-yamamoto/network-uri
>
> Note that they keep necessary commit history.
>
> In HP, only "HTTP" and "cgi" depends on "network" and they use
> "Network.URI". They can be compiled by just adding "network-uri" as
> dependency.  Also, "http-conduit" uses "Network.URI". This can also be
> compiled by adding "network-uri".
>
> For more information, please refer to:
>         https://github.com/haskell/network/issues/76
>
> Discussion period: 2 weeks
>
> --Kazu
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
Herbert Valerio Riedel | 8 Jan 11:14 2013
Picon

Re: Proposal: splitting the network package

[...]

> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only

+1
Bardur Arantsson | 8 Jan 15:08 2013
Picon

Re: Proposal: splitting the network package

On 01/08/2013 07:30 AM, Kazu Yamamoto (山本和彦) wrote:
> Hello,
> 
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
[--snip--]

+1

_______________________________________________
Libraries mailing list
Libraries <at> haskell.org
http://www.haskell.org/mailman/listinfo/libraries
Felipe Almeida Lessa | 9 Jan 14:39 2013
Picon

Re: Proposal: splitting the network package

+1.

On Tue, Jan 8, 2013 at 4:30 AM, Kazu Yamamoto <kazu <at> iij.ad.jp> wrote:
> Hello,
>
> The network package contains both socket modules and a URI
> module. They are in different level. Since new features are actively
> added to the socket modules, we may want to install a new network
> package even though Haskell Platform includes it. However, the
> Network.URI module depends on Parsec which depends on the text
> package. This sometimes causes dependency hell.
>
> I would like to propose to split the network package into:
> - new network package which contains socket modules only
> - network-uri package which contains Network.URI only
>
> Example implementations are available:
>         https://github.com/kazu-yamamoto/network/tree/no-uri
>         https://github.com/kazu-yamamoto/network-uri
>
> Note that they keep necessary commit history.
>
> In HP, only "HTTP" and "cgi" depends on "network" and they use
> "Network.URI". They can be compiled by just adding "network-uri" as
> dependency.  Also, "http-conduit" uses "Network.URI". This can also be
> compiled by adding "network-uri".
>
> For more information, please refer to:
>         https://github.com/haskell/network/issues/76
>
> Discussion period: 2 weeks
>
> --Kazu
>
> _______________________________________________
> Libraries mailing list
> Libraries <at> haskell.org
> http://www.haskell.org/mailman/listinfo/libraries

--

-- 
Felipe.
Gabriel Gonzalez | 9 Jan 18:56 2013
Picon

Re: Proposal: splitting the network package

I think the best action is to contact the maintainers.  I imagine that 
most package naming disputes can be resolved this way. Forcefully 
renaming packages crosses a point of no return, so we should be a little 
bit more hesitant to invoke that option.  If we do choose to rename 
package, though, then I think at a minimum the policy should be that:

* The package authors are unreachable
* There are no suitable alternative names

Also, I consider a social rating system (ala Hackage 2) the proper 
solution to finding the "one true" package for something, not package 
name space conflicts.
Felipe Almeida Lessa | 9 Jan 19:09 2013
Picon

Re: Proposal: splitting the network package

We could certainly allow two maintainers to share the same name of a
library.  For example, suffices to say that Alice will release only
even major versions while Bob will release odd major versions.  Since
users of the library will give restrictive constraints on the major
versions as per PVP, there won't be any clashes at all!  We could even
use a larger modulus, such as 7, in order to anticipate other
maintainers that may want to share the name of the library in future.

Yes, I'm joking =).

Cheers,

--
Felipe.
Ian Lynagh | 9 Jan 21:24 2013
Picon

Re: Proposal: splitting the network package

On Wed, Jan 09, 2013 at 09:56:35AM -0800, Gabriel Gonzalez wrote:
> I think the best action is to contact the maintainers.  I imagine
> that most package naming disputes can be resolved this way.

I agree; like I said:

    (although we'd obviously hope that the parties involved would normally
    come to an amicable agreement without having to go that far).

> Forcefully renaming packages crosses a point of no return, so we
> should be a little bit more hesitant to invoke that option.  If we
> do choose to rename package, though, then I think at a minimum the
> policy should be that:
> 
> * The package authors are unreachable
> * There are no suitable alternative names

Hmm, if that's the policy then maybe I should become a package-squatter.

There's currently no package called 'haskell', 'language' or
'concurrent', so those seem like good candidates to get started with.
I'll just upload some dummy packages now, and hope that I can sell the
rights to the names for $10 each in a few years time.

Of course, this is an extreme (and hypothetical) example, and I'm not
aware of any disputes thus far that haven't been resolved by the
relevant parties reaching an agreement by themselves.

But I think that it would be a lot better to make a decision about who
has the final say now, when we don't need it and can make the decision
impartially, than making it once we do need it, and opinions are biased
by the particular case that needs it first.

Thanks
Ian

Gmane