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@joachim-breitner.de | nomeata@debian.org | GPG: 0x4743206C xmpp: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/

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

On 10 January 2013 13:19, Kazu Yamamoto 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

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

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

On Wed, Jan 16, 2013 at 5:44 PM, Kazu Yamamoto 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.

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.

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

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

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

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

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

On 17/01/2013 12:22, Gregory Collins wrote:

On Thu, Jan 17, 2013 at 12:32 PM, 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.

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

On 17 January 2013 23:51, Gregory Collins wrote:

On Thu, Jan 17, 2013 at 1:37 PM, Graham Klyne 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.

On 18 January 2013 00:50, Bryan O'Sullivan wrote:

On Thu, Jan 17, 2013 at 8:38 AM, Conrad Parker 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.

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

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

On 31 January 2013 09:41, Kazu Yamamoto 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).

On Thu, Jan 31, 2013 at 12:28 PM, Henning Thielemann < lemming@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@haskell.org http://www.haskell.org/**mailman/listinfo/librarieshttp://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

On Thu, Jan 31, 2013 at 3:28 PM, Herbert Valerio Riedel wrote:

Michael Snoyman 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

On Fri, Feb 1, 2013 at 7:53 AM, Kazu Yamamoto 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@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

On Tue, Feb 5, 2013 at 12:40 AM, Johan Tibell wrote:

On Thu, Jan 31, 2013 at 10:05 PM, Michael Snoyman 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

Michael Snoyman 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

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 wrote:

On Wed, Feb 6, 2013 at 11:22 AM, Herbert Valerio Riedel wrote:

...

Michael Snoyman 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Gregory Collins

On Fri, Feb 8, 2013 at 8:40 AM, Kazu Yamamoto 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 [1] https://docs.google.com/document/d/1bGSlTB8RaFlztmTp4FW5tEH8UUex95969z-7wygk...

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