- web-devel - Haskell.org

Re: [Haskell-cafe] What is the maturity of Haskell Web Frameworks
by Sterling Clover 04 Jun '08

04 Jun '08

> > hvac sounds interesting but at that time at least it was not clear > whether it was stable or would continue to be maintained. > > xhtml and HStringTemplate were overkill for what I wanted, so I > wound up > just using the FastCGI and CGI toolkits themselves. They are > surprisingly nice, and with a little bit of wrappers around them for > things like validating forms, have worked exceptionally well. > I'm in a position now where I can make a reasonable promise that hvac will not only be maintained but undergoing continued development. I just, for example, hooked in some basic postgresql support yesterday (although the changes are not tested/pushed to the repo yet). (Speaking of which, I noticed that the HDBC postgresql bindings don't set seState on an error -- is this intentional, or something that should be fixed up?) As such though, I also can't promise that hvac as it stands is officially stable, although most work I imagine that will be done on it will consist of extensions rather than API-breaking changes. I've also been working on a lightweight testing API for programs using the CGI monad, integrated with quickcheck. Although this project isn't "final" yet either, there's a working repo at http:// code.haskell.org/~sclv/cgicheck/ if anyone wants to play with it/use it. I plan to use this quite a bit to test hvac, and any applications produced using it. Additionally, the hvac code now has a nice, though also incomplete orm/dsl-type library for database access (also built on top of HDBC). When I feel more confident/polished in the code there, I plan to split it out and hackage it as well. Of course, folks with a little time/inclination who play with these things a bit and put them through the paces are a big help in working out the kinks such that I feel they're closer to "release- quality" (even if that "release" *is* only 0.1). :-) Relatedly, I'd be very interested in developing a single common library for encoding/escaping/decoding/unescaping of common web formats (urls, javascript, basic xss escaping, rss-valid character escapes to html-valid ones, etc.) that uses a lightweight invertible combinator approach as described in Pierce's work on lenses (various papers at http://www.seas.upenn.edu/~harmony/) such that the encode/ decode methods are correct-by-construction bijections. There are various encoding bits scattered among the Haskell web libraries at the moment, each with varying degrees of correctness and conformance. It would be nice to direct energy here to a single centralized project, which would have some upfront architecture, and then, unfortunately, probably no small degree of spec-translation. If anyone else is interested in working on such a thing, I'd be delighted for ideas/collaboration (or better yet, if someone just picked up the idea and ran with it themselves!) (hmm... maybe galois has some internal libraries it wouldn't mind sharing as a partial basis?) Regards, Sterl.

1 0

Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Michaeljohn Clement 13 Apr '08

13 Apr '08

Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: >> * Using a different set of data types would work better. > > Give that this is Haskell, I'd suggest more types ;) > > HTTP headers aren't just strings and, at the risk of tooting my own > horn, I'll point to the Headers structure in [1]. That is one of the things I don't like about Network.HTTP, which also enumerates header fields. It is inconvenient to have to look up the names in the data type, when the standard field names are already known, and it makes using non-RFC2616 headers less convenient. Automatic parsing of header fields also makes unusual usage inconvenient, (for example the Range header support in [1] is a profile of RFC2616.) I think those kinds of features belong in frameworks; they will be more of an annoyance than a help to anyone that is writing to the WSGI layer. > Likewise, URLs have > lots of structure that should just be handled in one place [2] Yes, I think should be parsed to the level of granularity specified by RFC 2616 (i.e. scheme, host, port, path, query string) and anything more (like parsing query strings) should be handled by frameworks. > > [1] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;… > [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;… > > > AGL > -- Michaeljohn Clement

1 0

RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Johan Tibell 13 Apr '08

13 Apr '08

Good day hackers, The Python community have been successful in standardizing an interface between web server and applications or frameworks resulting in users having more control over their web stack by being able to pick frameworks independently from web servers, and vice versa. I propose we try to do the same for Haskell. I've written half a draft for a Haskell version of Python's PEP 333 [1]. If you're interested in taking part in this effort please read through the Python spec first (as it is way more complete and you can understand this proposal better by reading it, I've skipped some important issues in my first draft) and then go read the Haskell spec [2]. I'm particularly interesting in feedback regarding: * Doing in this way won't work as it violates HTTP/CGI spec part X, Y and Z (the Python spec takes lots of things from the CGI spec including naming and semantics). * My server/framework could never provide/be run under this interface. * This interface has bad performance by design. * Using a different set of data types would work better. The spec needs to be extended to cover all the corners of HTTP. Some parts need to be motivated better. It is easier for me to motivate things if people would tell me what parts are badly motivated. Note: I'm open to a complete rewrite if needed. I'm not wedded to the current design and/or wording. In fact parts of the wording is borrowed from the Python spec. The parts with bad grammar are all mine. 1. http://www.python.org/dev/peps/pep-0333/ 2. http://www.haskell.org/haskellwiki/WebApplicationInterface -- Johan

3 2

Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI)
by Daniel McAllansmith 13 Apr '08

13 Apr '08

On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > > * Using a different set of data types would work better. > > Give that this is Haskell, I'd suggest more types ;) > > HTTP headers aren't just strings and, at the risk of tooting my own > horn, I'll point to the Headers structure in [1]. And it could go further. The use of a given header is often valid only in certain requests or responses. Perhaps sprinkling some phantom types or type classes around could represent that. Daniel

1 0

Fwd: ANN / CFC: minimalistic haskell blogging web application (perpubplat)
by Paul Brown 04 Jan '08

04 Jan '08

Cross-posting from Haskell-Cafe: ---------- Forwarded message ---------- From: Paul Brown <paulrbrown+haskell-cafe(a)gmail.com> Date: Jan 4, 2008 12:43 PM Subject: ANN / CFC: minimalistic haskell blogging web application (perpubplat) To: haskell-cafe <haskell-cafe(a)haskell.org> All -- I've spent some time on cleaning up my hobby blog publishing software and setting up a darcs repository, so I'll throw it out there for criticism or suggestions: darcs get http://datapr0n.com/repos/perpubplat It's running my blog (http://mult.ifario.us) It's relatively lightweight in that it doesn't use a framework but still weighs in at <1500 LOC with comments, but it does rely on the (Thanks, Bjorn!) FastCGI and XHTML combinator libraries. I have some plans for handling comments and the like, but things I'd like to figure out: - Turn the blog data model into a monad. - An idiomatic approach to handling conditional GET and E-Tag, i.e., send a 304 response if things aren't modified. Thanks in advance. -- paulrbrown(a)gmail.com http://mult.ifario.us/ -- paulrbrown(a)gmail.com http://mult.ifario.us/

1 0

[farmand@linagora.com: [Ocsigen] Functional Web Frameworks groups]
by Marc Weber 19 Nov '07

19 Nov '07

Perhaps you are intersted in this as well. Marc W. ----- Forwarded message from Francois Armand <farmand(a)linagora.com> ----- Date: Mon, 19 Nov 2007 07:44:05 +0100 From: Francois Armand <farmand(a)linagora.com> To: ocsigen(a)sympa.pps.jussieu.fr Subject: [Ocsigen] Functional Web Frameworks groups Hi Ocsigen, The world of functional web frameworks seems to be an hot place in these days ! David Pollak of Lift Web (Scala web framework : http://liftweb.net/) has just created a google group to exchange on this topic. It seems to already be some people from Erlyweb (Erlang) and HAppS (Haskel) there, so it really lacks for OCaml advocates ;) Hope to see you there, -- Francois Armand Etudes & Développements J2EE Groupe Linagora - http://www.linagora.com Tél.: +33 (0)1 58 18 68 28 ----------- InterLDAP - http://interldap.org FederID - http://www.federid.org/ Open Source identities management and federation ----- End forwarded message -----

1 0

Re: [web-devel] Scope of this mailing list
by PR Stanley 19 Jun '07

19 Jun '07

For any future queries regarding Web-Devel please feel free to drop me a line at prstanley at ntlworld.com Regards Paul (list owner/moderator)

2 2

Scope of this mailing list
by Neil Mitchell 18 Jun '07

18 Jun '07

Hi I've been developing the tagsoup library, which deals with parsing HTML, which is clearly a web-development task. I'm now wanting to use a mailing list to discuss the further development of tagsoup - I can either set up a separate mailing list, or use this one - which seems to overlap. So would the people in this mailing list rather I just set up a separate tagsoup mailing list (I'm not expecting massive amounts of traffic), or use this one? Thanks Neil [1] http://www-users.cs.york.ac.uk/~ndm/tagsoup/

3 2

Strange HAppS problem (tutorial)
by John Melesky 07 May '07

07 May '07

So, i'm working my way through the HAppS tutorial ( http:// www.haskell.org/haskellwiki/HAppS_tutorial ), and i get to section 3.2. I type in the code, it builds fine, but when i run it, i get the following error: hello: user error (decodeStringM: parsing length field failed @ "") However (and this is the strange part), if i just runghc the .hs file, it all works fine. This is running ghc 6.6, darwinports version, on intel OSX 10.4.9, however i've verified the same behavior on ghc, Audrey Tang's bundle, G4 OSX 10.4.9 (for whatever that's worth). Anyone have any ideas? Anyone run into this before? -johnnnnnnn

2 2

Parse HTTP headers
by Henning Thielemann 10 Apr '07

10 Apr '07

First of all, I want to say that I like Network.HTTP.HeaderName being an enumeration like type because of the advantages that are listed in the HTTP module. HeaderName has a Show instance which shows the header name as the HTTP protocoll requires that. I don't find it good, since I like to copy output values in GHCi back to the GHCi prompt. I'm missing a Read instance or a parsing routine to convert String -> HeaderName. I want to do the following: I download HTML pages from the web which may contain META-HTTP-EQUIV tags. I want to merge the HTTP header, that I got from the web server, with the META information of the downloaded HTML page. I like to merge them in terms of HTTP.Header, not in terms of (String,String) and I also like to have a function like HTTP.findHeader to extract some information from this list. (Currently I'm mainly interested in Content-Type and Content-Language.)

2 1