blaze-builder is basically a necessity for any serious web application these days: both Warp and Snap depend on it, and I believe Happstack will in the near future. text is a dependency of blaze-builder, and moreover, WAI is using the text datatypes directly, so it also needs to be there. case-insensitive is basically there for convenience: it's nice to have a single package providing a datatype everyone can use. I also agree that base-unicode-symbols doesn't really add anything, but I didn't really bother with asking for it to be removed. If it becomes an issue, maybe Bas will consider dropping it as a dependency. On Mon, Mar 28, 2011 at 11:20 AM, Christian Maeder wrote:

I skimmed through it (I'm still using wai-extra-0.2.4.2)

There's not much code left to comment on. I'll have to get used to the new Response data type, though.

I'm sort of shocked by the many dependencies (already via http-types) on blaze-builder, text, case-insensitive and (really unnecessarily) on base-unicode-symbols.

So I'll rather expect problems in dependent packages than in wai.

Thanks for your work!

Cheers Christian

Am 28.03.2011 09:02, schrieb Michael Snoyman:

...

Hi all,

Just wanted to give everyone a last chance to give input on WAI 0.4 before its release. You can see the code on Github[1]. The main things to point out in this release are:

* We've switched to using http-types, so WAI needs to define much less on its own (i.e., statuses, HTTP versions, etc). Additionally, we now rely on the case-insensitive library for header keys. * The Request datatype now contains parsed pathInfo and queryString. This makes it more efficient to write middlewares. The raw path info and query string are still available as rawPathInfo and rawQueryString, respectively. * Partial file responses are now supported. The ResponseFile constructor takes a fourth argument, Maybe FilePart. FilePart contains the offset and count.

If anyone has other ideas that they'd like to see implemented in WAI, please get them in sooner, rather than later. I'm hoping that this release will last for quite a while. We'll also be releasing a number of associated packages at the same time (wai-extra, warp, wai-test, etc), so if you have comments on those, feel free to submit them as well.

Michael

[1] https://github.com/snoyberg/wai/blob/master/Network/Wai.hs

BTW, this blaze-builder dependency will go away/become more standard in the future, when the Builder work is integrated into the 'bytestring' library. Although, that might still take some time, as my current pace is best described as "slow but steady". best, Simon 2011/3/28 Jasper Van der Jeugt

happstack-server [1] already depends on blaze-html, and blaze-html depends on blaze-builder, so the latter indeed a pretty common dependency these days.

[1]: http://hackage.haskell.org/package/happstack-server

Cheers, Jasper

On Mon, Mar 28, 2011 at 11:34 AM, Michael Snoyman wrote:

...

blaze-builder is basically a necessity for any serious web application these days: both Warp and Snap depend on it, and I believe Happstack will in the near future. text is a dependency of blaze-builder, and moreover, WAI is using the text datatypes directly, so it also needs to be there.

case-insensitive is basically there for convenience: it's nice to have a single package providing a datatype everyone can use. I also agree that base-unicode-symbols doesn't really add anything, but I didn't really bother with asking for it to be removed. If it becomes an issue, maybe Bas will consider dropping it as a dependency.

On Mon, Mar 28, 2011 at 11:20 AM, Christian Maeder wrote:

...

I skimmed through it (I'm still using wai-extra-0.2.4.2)

There's not much code left to comment on. I'll have to get used to the new Response data type, though.

I'm sort of shocked by the many dependencies (already via http-types) on blaze-builder, text, case-insensitive and (really unnecessarily) on base-unicode-symbols.

So I'll rather expect problems in dependent packages than in wai.

Thanks for your work!

Cheers Christian

Am 28.03.2011 09:02, schrieb Michael Snoyman:

...

Hi all,

Just wanted to give everyone a last chance to give input on WAI 0.4 before its release. You can see the code on Github[1]. The main things to point out in this release are:

* We've switched to using http-types, so WAI needs to define much less on its own (i.e., statuses, HTTP versions, etc). Additionally, we now rely on the case-insensitive library for header keys. * The Request datatype now contains parsed pathInfo and queryString. This makes it more efficient to write middlewares. The raw path info and query string are still available as rawPathInfo and rawQueryString, respectively. * Partial file responses are now supported. The ResponseFile constructor takes a fourth argument, Maybe FilePart. FilePart contains the offset and count.

If anyone has other ideas that they'd like to see implemented in WAI, please get them in sooner, rather than later. I'm hoping that this release will last for quite a while. We'll also be releasing a number of associated packages at the same time (wai-extra, warp, wai-test, etc), so if you have comments on those, feel free to submit them as well.

Michael

[1] https://github.com/snoyberg/wai/blob/master/Network/Wai.hs

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

CCing Bas. Any chance of dropping the base-unicode-symbols from the case-insensitive package? Michael On Tue, Mar 29, 2011 at 8:54 PM, Neil Mitchell wrote:

...

I'm sort of shocked by the many dependencies (already via http-types) on blaze-builder, text, case-insensitive and (really unnecessarily) on base-unicode-symbols.

As far as I am aware, base-unicode-symbols only works on GHC 6.12 and above. For Hoogle, which uses WAI, I deliberately try and work on GHC version 6.10 as well - GHC 7 is only very just out, and a version which is basically functional for most users has only been released in the last week - making 6.10 effectively the release before last. Excluding 6.10 for good reasons is fine, excluding it for a fairly unnecessary dependency makes me sad.

Thanks, Neil

Hi, The UnicodeSyntax extension was already supported by GHC 6.8.1. I just released a new version of base-unicode-symbols (0.2.1.2) which also works with base-3.0. This means you can now build the package with GHC 6.8.1 and with every newer release. The base-unicode-symbols package itself is usually an internal dependency. It is not part of the interface of any of its reverse dependencies. Because it is a tiny package the build times are insignificant. On my system a "cabal install base-unicode-symbols" takes 2 seconds and takes up 300KB of disk space. To conclude: Whether some package X depends on base-unicode-symbols or not doesn't matter from the perspective of the users of said package X. On 29 March 2011 20:54, Neil Mitchell wrote:

...

I'm sort of shocked by the many dependencies (already via http-types) on blaze-builder, text, case-insensitive and (really unnecessarily) on base-unicode-symbols.

As far as I am aware, base-unicode-symbols only works on GHC 6.12 and above. For Hoogle, which uses WAI, I deliberately try and work on GHC version 6.10 as well - GHC 7 is only very just out, and a version which is basically functional for most users has only been released in the last week - making 6.10 effectively the release before last. Excluding 6.10 for good reasons is fine, excluding it for a fairly unnecessary dependency makes me sad.

Thanks, Neil

I think it's more of a readability thing, than replacing symbols for fun. -- Markus Läll On Wed, Mar 30, 2011 at 4:56 PM, Christian Maeder wrote:

Am 30.03.2011 15:31, schrieb Roel van Dijk:

...

Hi,

The UnicodeSyntax extension was already supported by GHC 6.8.1. I just released a new version of base-unicode-symbols (0.2.1.2) which also works with base-3.0. This means you can now build the package with GHC 6.8.1 and with every newer release.

The base-unicode-symbols package itself is usually an internal dependency. It is not part of the interface of any of its reverse dependencies. Because it is a tiny package the build times are insignificant. On my system a "cabal install base-unicode-symbols" takes 2 seconds and takes up 300KB of disk space.

To conclude: Whether some package X depends on base-unicode-symbols or not doesn't matter from the perspective of the users of said package X.

Still such toy stuff does not belong into production code and is possibly just a stupid burden for other tools processing haskell source code.

C.

...

On 29 March 2011 20:54, Neil Mitchell wrote:

...

I'm sort of shocked by the many dependencies (already via http-types) on

...

blaze-builder, text, case-insensitive and (really unnecessarily) on base-unicode-symbols.

As far as I am aware, base-unicode-symbols only works on GHC 6.12 and above. For Hoogle, which uses WAI, I deliberately try and work on GHC version 6.10 as well - GHC 7 is only very just out, and a version which is basically functional for most users has only been released in the last week - making 6.10 effectively the release before last. Excluding 6.10 for good reasons is fine, excluding it for a fairly unnecessary dependency makes me sad.

Thanks, Neil

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Wed, Mar 30, 2011 at 4:41 PM, Chris Smith wrote:

On Wed, 2011-03-30 at 17:25 +0300, Markus Läll wrote:

...

I think it's more of a readability thing, than replacing symbols for fun.

It's certainly, at best, an odd choice.  Given the tools we have today, it is something that every indirect user of the library needs to worry about.  It also drastically reduces the number of people who might contribute to the code, to those who have either memorized unicode code points or set up editor macros for characters that aren't on any keyboard I'm aware of.  In return, you get... what?  The ordinary Haskell names for things will still be around anyway, so now you just have to recognize two names for the same thing, one of which you may not even know how to type, and know that they mean the same thing.

That said, I'm not in the WAI user pool, so this doesn't affect me in the short term.  I'm just an interested observer.  And while I hope that after another year or two of experience we might all end up using some common code that plays a role similar to WAI, a dependency on this package is nowhere close to the biggest obstacle to overcome to reach that point.

Out of curiosity... what *is* the biggest obstacle to overcome? Michael

On Wed, Mar 30, 2011 at 5:50 PM, Chris Smith wrote:

On Wed, 2011-03-30 at 16:45 +0200, Michael Snoyman wrote:

...

Out of curiosity... what *is* the biggest obstacle to overcome?

Time and learning.  The current incarnation of web application development in Haskell is still very new -- less than a year old, unless you're Happstack? -- and we're still learning the right way to do it. WAI, for instance, wouldn't be anywhere near the quality it is today if every change had been met with the need to coordinate compatibility issues with three significant communities of developers prior to a release.

Not being one of the people who've built a web server or web application framework or similar in Haskell (my newfound role as a Snap developer is fairly limited), I wouldn't presume to say too much.  But things are still changing rapidly, and smart people who *have* built these things still see some benefit in maintaining their own alternatives.  I'm encouraged by some of the convergence of design decisions (which even extends beyond just web frameworks; blaze-builder in the bytestring package will be very nice for many kinds of Haskell applications), and it looks like we're getting there.

There's no need to be in a hurry about it.  Standardization is great once you know you've got the right design.

Sounds like a good answer :). I was just curious if you had a specific thought in mind with your comment. Michael

I share this opinion. A package like case-insensitive doesn't expose non-ASCII characters in its interface. Whether it uses such characters internally is of little importance for dependencies. Even if you want to hack on case-insensitive itself there is nothing forcing you to use these characters. We would never reject a patch for not using our favourite symbols. On 30 March 2011 17:50, Markus Läll wrote:

Well, I'm biased, because I like what the package does.

I guess I can see how it could be a showstopper for someone who doesn't want to dive into *another* something, that doesn't actually affect how the program performs. But this is only when you read (and want to contrubute to) code, that uses it directly. Otherwise, if using unicode, there should be nothing to worry about -- the equivalent names are always there to use...

Hi Chris, This is likely caused by the bug John Obbele found last night: http://www.haskell.org/pipermail/haskell-cafe/2011-March/090605.html I accidentally inverted the logic of a flag (Oops!). This should be fixed in version 0.2.1.4. I have tested it with GHC-6.12.1. Thanks for the bug report! On 31 March 2011 15:35, Chris Smith wrote:

Unfortunately, it doesn't seem to build with 6.12.1.  I get unrecognized symbols for (>>>) and (<<<) in Control.Arrow.Unicode.  Looks like something is wrong with the conditional version pragmas?  I was able to work around it by making my project, which used http-enumerator, depend on 0.2.1.1 directly so that Cabal chooses that version.

It probably won't have any affect on Yesod. However, the next version of Yesod is making some parallel changes, namely switching over to the Text datatype whenever possible. It should help out performance a bit (less marshaling data around, using packed representation, etc). But I'm mostly doing it for consistency. For the record: I'm hoping to make a Yesod 0.8 release fairly soon, and I don't anticipate that very much 0.7 code will break with the new release. Getting WAI 0.4 out the door is the first step in this process. Michael On Mon, Mar 28, 2011 at 11:27 AM, Anton Cheshkov wrote:

I have a question: how WAI 0.4 will affect on yesod API ?

Thanks. 2011/3/28 Michael Snoyman

...

Hi all,

Just wanted to give everyone a last chance to give input on WAI 0.4 before its release. You can see the code on Github[1]. The main things to point out in this release are:

* We've switched to using http-types, so WAI needs to define much less on its own (i.e., statuses, HTTP versions, etc). Additionally, we now rely on the case-insensitive library for header keys. * The Request datatype now contains parsed pathInfo and queryString. This makes it more efficient to write middlewares. The raw path info and query string are still available as rawPathInfo and rawQueryString, respectively. * Partial file responses are now supported. The ResponseFile constructor takes a fourth argument, Maybe FilePart. FilePart contains the offset and count.

If anyone has other ideas that they'd like to see implemented in WAI, please get them in sooner, rather than later. I'm hoping that this release will last for quite a while. We'll also be releasing a number of associated packages at the same time (wai-extra, warp, wai-test, etc), so if you have comments on those, feel free to submit them as well.

Michael

[1] https://github.com/snoyberg/wai/blob/master/Network/Wai.hs

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

-- Best regards, Cheshkov Anton Phone: +7 909 005 18 82 Skype: cheshkov_anton

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Wed, Mar 30, 2011 at 5:58 PM, Bas van Dijk wrote:

On 28 March 2011 09:02, Michael Snoyman wrote:

...

Just wanted to give everyone a last chance to give input on WAI 0.4 before its release.

Hi Michael,

What's the role of the errorHandler :: String -> IO () in the Request type: https://github.com/snoyberg/wai/blob/master/Network/Wai.hs#L73 ? It seems a bit odd to have this in a request.

Thanks,

Bas

The idea is to allow the server to give the application a general way of logging error messages. Frankly, I don't personally use it at all, and it was a relic from when I was trying to merge the original WAI (proposed by Johan) and Hack. Do people have ideas on how to make it more useful, or perhaps a better name for it? This is probably a good area for improvement. Michael

On Wed, Mar 30, 2011 at 6:15 PM, Bas van Dijk wrote:

On 30 March 2011 18:01, Michael Snoyman wrote:

...

On Wed, Mar 30, 2011 at 5:58 PM, Bas van Dijk wrote:

...

On 28 March 2011 09:02, Michael Snoyman wrote:

...

Just wanted to give everyone a last chance to give input on WAI 0.4 before its release.

Hi Michael,

What's the role of the errorHandler :: String -> IO () in the Request type: https://github.com/snoyberg/wai/blob/master/Network/Wai.hs#L73 ? It seems a bit odd to have this in a request.

Thanks,

Bas

The idea is to allow the server to give the application a general way of logging error messages. Frankly, I don't personally use it at all, and it was a relic from when I was trying to merge the original WAI (proposed by Johan) and Hack. Do people have ideas on how to make it more useful, or perhaps a better name for it? This is probably a good area for improvement.

Thanks for the explanation. I think it makes more sense to either remove the error handler or move it to the Application as in:

type Application = ErrorHandler -> Request -> Iteratee B.ByteString IO Response

type ErrorHandler = String -> IO ()

Bas

Moving it to Application like that will simply make it more difficult to write Middlewares. I think I understand the theoretical advantage, but I don't think there's a practical advantage here. Michael

Hello,

2) None of the WAI backends do anything particularly intelligent with the data. I think they all just print to stderr.

It's OK for me to remove errorHandle from Request. But I want "warp" to provide a hook to handle errors. That is, please don't remove settingsOnException from Settings and you don't have to pass it to each Request but please use it inside of warp. --Kazu

* runSettings allows configuring all settings (for now, port, exception handler and timeout) * runSettingsSocket allows you to provide both the Settings and the socket to be listened on

Sounds good to me! --Kazu