From paulrbrown at gmail.com Fri Jan 4 16:51:09 2008 From: paulrbrown at gmail.com (Paul Brown) Date: Fri Jan 4 16:45:01 2008 Subject: [web-devel] Fwd: ANN / CFC: minimalistic haskell blogging web application (perpubplat) In-Reply-To: <4249453d0801041243i2b656ec7y1038e05a6aa44480@mail.gmail.com> References: <4249453d0801041243i2b656ec7y1038e05a6aa44480@mail.gmail.com> Message-ID: <4249453d0801041351u4a9a4296k7f573006e92c19d2@mail.gmail.com> Cross-posting from Haskell-Cafe: ---------- Forwarded message ---------- From: Paul Brown Date: Jan 4, 2008 12:43 PM Subject: ANN / CFC: minimalistic haskell blogging web application (perpubplat) To: haskell-cafe 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@gmail.com http://mult.ifario.us/ -- paulrbrown@gmail.com http://mult.ifario.us/ From johan.tibell at gmail.com Sun Apr 13 07:59:45 2008 From: johan.tibell at gmail.com (Johan Tibell) Date: Sun Apr 13 07:55:06 2008 Subject: [web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) Message-ID: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> 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 From dm.maillists at gmail.com Sun Apr 13 21:08:56 2008 From: dm.maillists at gmail.com (Daniel McAllansmith) Date: Sun Apr 13 21:04:31 2008 Subject: [web-devel] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <200804141308.56697.dm.maillists@gmail.com> On Mon, 14 Apr 2008 11:06:43 Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell 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 From s.clover at gmail.com Sun Apr 13 22:43:33 2008 From: s.clover at gmail.com (Sterling Clover) Date: Sun Apr 13 22:38:55 2008 Subject: [web-devel] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <368E0883-A910-4FFD-937F-A6A1D7F88E42@gmail.com> In a sense, the CGIT interface provided by Network.CGI already is a sort of halfway implementation of what we're discussing, no? I'd be interested in approaching this from the other way -- specifying exactly what CGIT doesn't provide and therefore what folks want to see. As far as I can tell, the main issue with CGIT is that it doesn't handle streaming/resource issues very well. The main innovation I see provided here is the enumerator interface, which is a very nice and flexible approach to I/O and provides a way to handle comet cleanly to boot. Since the application type as proposed is Env -> IO (Code, Headers, ResponseEnumerator), what we're really getting is almost an equiv. (modulo enumerators) of unwrapping CGIT IO CGIResponse with a run function. So what we lose is the ability for all our nicely named record accessors and functions to be shared across frameworks -- i.e. the flexibility a monad transformer *does* provide. So my question is if we can somehow preserve that with an appropriate typeclass. I'd ideally like to see this engineered in two parts -- a "cgit-like" typeclass interface that allows access to the environment but is agnostic as to response type, so that comet-style and other apps that take special advantage of enumerators can be built on top of it as well as apps that simply perform lazy writes; and the lower-level enumerator interface. This ideally would let the higher-level interface be built over any stack at all (i.e. STM-based as well, or even a pure stack), while the lower level interface that calls it is some glue of the given constant type in the IO monad. This would be of great help to hvac. There's also the fact that this could be designed ground-up with greater bytestring use, but that doesn't seem immense to me. Outside of this, I'm not quite sure what else CGIT lacks. I'm with Chris Smith's arguments as to the headers question, and it seems to me that dicts are best done using MVar-style primitives. I'm a bit at sea as to why the queryString is here just represented as a bytestring -- is it seriously an issue that some apps may want to use it other than in the standard parsed way? Is the idea here that lib functions would fill in and be shared among frameworks? On the other hand, seperating GET and POST vars is a good idea, and its a shame that CGIT doesn't allow this. The openness here seems in part based on the desire to keep different forms of file upload handling available. However, the work that oleg did with regards to CGI also seems promising -- i.e., rather than using an enumerator, simply taking advantage of laziness to unpack the input stream into a lazy dictionary. Regards, S. On Apr 13, 2008, at 7:59 AM, Johan Tibell wrote: > 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 > _______________________________________________ > web-devel mailing list > web-devel@haskell.org > http://www.haskell.org/mailman/listinfo/web-devel From mj at mjclement.com Sun Apr 13 23:31:54 2008 From: mj at mjclement.com (Michaeljohn Clement) Date: Sun Apr 13 23:27:20 2008 Subject: [web-devel] Re: [Haskell-cafe] RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> Message-ID: <4802D02A.9070203@mjclement.com> I am very interested in this work. One thing missing is support for all HTTP methods, not just those in RFC 2616. As-is, something like WebDAV cannot be implemented. That probably means requestMethod should be a (Byte)String. What about something like sendfile(2) available on some platforms? To allow the server to make use of such optimizations, how about an optional alternative to the enumerator? Perhaps the app can optionally pass a path or an open fd back to the server in place of an enumerator, which allows servers to do any kind of buffering optimizations, etc, that they may know about, as well as using any platform-specific optimizations like sendfile. -- Michaeljohn Clement From mj at mjclement.com Sun Apr 13 23:50:48 2008 From: mj at mjclement.com (Michaeljohn Clement) Date: Sun Apr 13 23:46:16 2008 Subject: [web-devel] Re: [Haskell-cafe] Re: RFC: A standardized interface between web servers and applications or frameworks (ala WSGI) In-Reply-To: <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> References: <90889fe70804130459u25bf182dvf4bec5ca69d6112e@mail.gmail.com> <396556a20804131606h35c0cd75p2076fd20bdd67582@mail.gmail.com> Message-ID: <4802D498.7000303@mjclement.com> Adam Langley wrote: > On Sun, Apr 13, 2008 at 4:59 AM, Johan Tibell 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;f=/Network/MiniHTTP/Marshal.hs > [2] http://darcs.imperialviolet.org/darcsweb.cgi?r=network-minihttp;a=headblob;f=/Network/MiniHTTP/URL.hs > > > AGL > -- Michaeljohn Clement From s.clover at gmail.com Wed Jun 4 15:00:08 2008 From: s.clover at gmail.com (Sterling Clover) Date: Wed Jun 4 14:52:50 2008 Subject: [web-devel] Re: [Haskell-cafe] What is the maturity of Haskell Web Frameworks In-Reply-To: <4846C559.9020201@complete.org> References: <20080602172131.GA7534@scytale.galois.com> <910ddf450806031020i2e09b83bo4cd13f395b612e1@mail.gmail.com> <20080603172303.GA22053@scytale.galois.com> <1212534382.15010.227.camel@localhost> <4846C559.9020201@complete.org> Message-ID: <84455758-6AD3-4FE9-ABF8-C1FC739FE0ED@gmail.com> > > 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. From marco-oweber at gmx.de Fri Sep 12 19:15:27 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Fri Sep 12 19:13:10 2008 Subject: [web-devel] VXML - validating XHTML library Message-ID: <20080912231527.GB27403@gmx.de> Hi @ll. Those of you reading the haskelcafe mailinglist already know that I've been working on vxml. It's a library letting you write XHTML code validating the result at compilation time against a given dtd. How does it work? Given a doctype like this : results in a set of state transformation rules. A new empty root tag starts with the State1. From that on it's fed with either y or z (using functional dependencies) resulting a new state 1 or 7. If you add an subelement y the state changes to 7 which is not endable forcing you to add another element. etc.. State 1 endable : True y -> St 7 z -> St 1 State2 :7 endable : False y -> St 7 z -> St 1 Use this on a xhtml dtd and you'll get about 500 different states and a lot of instances. Luckily most elements are described this way: (PCDATA|div|form|...)* this means that the sate does not change after an element which should enable you to use foldr functions or such without type hackery (? I have to verify this).. Validation errors are denoted this way: * wrong element (1): "No instance for (Consume State4 (Elem B_T) st')" * more elements expected (1): "No instance for (ElEndable Root_T State4)" * invalid attribute: "No instance for (AttrOk Root_T AAttr_A)" * duplicate attribute: "No instance for (Text.XML.Validated.Types.DuplicateAttribute A_T AAttr_A)" * missing required attributes: "No instance for (Text.XML.Validated.Types.RequiredAttributesMissing Root_T (HCons (A RootAttr_A) HNil))" Using ghc head you can rebind >>= and >> and use a do like notation: #if (__GLASGOW_HASKELL__ > 608) #include "vxmldos.h" tDo $ runHtmlDoc $ vdo head $ title $ text "text" body $ vdo script $ X.type "text/javascript" >> text "document.writeln('hi');" h2 $ text "That's a headline, hello and how do you do?" -- br e eg a
is not allowed here div $ vdo onclick "alert('clicked');" styleA "color:#F79" text "text within the div" div e return "That's nice, isn't it?" resulting in: returned value : "That's nice, isn't it?" xml : text

That's a headline, hello and how do you do?

text within the div
where vxmldos.h includes some macros rebinding >>=, >>, return and lift If you want to jump in, test and give some feedback you're welcome. Grab the code from git://mawercer.de/vxml If you feel there is some documentation missing just ask. Sincerly Marc Weber From prstanley at ntlworld.com Fri Sep 12 20:05:04 2008 From: prstanley at ntlworld.com (P. R. Stanley) Date: Fri Sep 12 20:02:32 2008 Subject: [web-devel] VXML - validating XHTML library In-Reply-To: <20080912231527.GB27403@gmx.de> References: <20080912231527.GB27403@gmx.de> Message-ID: <20080913000452.VPG19289.aamtaout02-winn.ispmail.ntl.com@pine.ntlworld.com> Just out of interest, why DTD and not XSchema? I would have thought the latter were more complete in many respects. Paul At 00:15 13/09/2008, you wrote: >Hi @ll. > >Those of you reading the haskelcafe mailinglist already know that I've >been working on vxml. It's a library letting you write XHTML code >validating the result at compilation time against a given dtd. > >How does it work? >Given a doctype like this : > > > > > >results in a set of state transformation rules. A new empty root tag >starts with the State1. From that on it's fed with either y or z (using >functional dependencies) resulting a new state 1 or 7. If you add an >subelement y the state changes to 7 which is not endable forcing you to >add another element. etc.. > > State 1 > endable : True > y -> St 7 > z -> St 1 > > State2 :7 > endable : False > y -> St 7 > z -> St 1 > >Use this on a xhtml dtd and you'll get about 500 different states and a >lot of instances. Luckily most elements are described this way: >(PCDATA|div|form|...)* >this means that the sate does not change after an element which should >enable you to use foldr functions or such without type hackery (? I have >to verify this).. > >Validation errors are denoted this way: > > * wrong element (1): > "No instance for (Consume State4 (Elem B_T) st')" > > * more elements expected (1): > "No instance for (ElEndable Root_T State4)" > > * invalid attribute: > "No instance for (AttrOk Root_T AAttr_A)" > > * duplicate attribute: > "No instance for (Text.XML.Validated.Types.DuplicateAttribute > A_T AAttr_A)" > > * missing required attributes: > "No instance for (Text.XML.Validated.Types.RequiredAttributesMissing > Root_T (HCons (A RootAttr_A) HNil))" > > >Using ghc head you can rebind >>= and >> and use a do like notation: > > #if (__GLASGOW_HASKELL__ > 608) > #include "vxmldos.h" > tDo $ runHtmlDoc $ vdo > head $ title $ text "text" > body $ vdo > script $ X.type "text/javascript" >> text "document.writeln('hi');" > h2 $ text "That's a headline, hello and how do you do?" > -- br e eg a
is not allowed here > div $ vdo > onclick "alert('clicked');" > styleA "color:#F79" > text "text within the div" > div e > return "That's nice, isn't it?" > > resulting in: > returned value : "That's nice, isn't it?" > xml : "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > text

That's a > headline, hello and how do you do?

onclick="alert('clicked');" style="color:#F79">text within the > div
> >where vxmldos.h includes some macros rebinding >>=, >>, return and lift > >If you want to jump in, test and give some feedback you're welcome. >Grab the code from git://mawercer.de/vxml >If you feel there is some documentation missing just ask. > >Sincerly > Marc Weber >_______________________________________________ >web-devel mailing list >web-devel@haskell.org >http://www.haskell.org/mailman/listinfo/web-devel From marco-oweber at gmx.de Sat Sep 13 18:44:56 2008 From: marco-oweber at gmx.de (Marc Weber) Date: Sat Sep 13 18:42:37 2008 Subject: [web-devel] VXML - validating XHTML library In-Reply-To: <20080913000452.VPG19289.aamtaout02-winn.ispmail.ntl.com@pine.ntlworld.com> References: <20080912231527.GB27403@gmx.de> <20080913000452.VPG19289.aamtaout02-winn.ispmail.ntl.com@pine.ntlworld.com> Message-ID: <20080913224456.GA5120@gmx.de> On Sat, Sep 13, 2008 at 01:05:04AM +0100, Paul Stanley wrote: > Just out of interest, why DTD and not XSchema? I would have thought the > latter were more complete in many respects. I didn't kewn about it and I knew XHTML is defined by dtd which I was interested in. Greetings Marc From prstanley at ntlworld.com Sat Sep 13 22:31:45 2008 From: prstanley at ntlworld.com (P. R. Stanley) Date: Sat Sep 13 22:29:24 2008 Subject: [web-devel] VXML - validating XHTML library In-Reply-To: <20080913224456.GA5120@gmx.de> References: <20080912231527.GB27403@gmx.de> <20080913000452.VPG19289.aamtaout02-winn.ispmail.ntl.com@pine.ntlworld.com> <20080913224456.GA5120@gmx.de> Message-ID: <20080914023147.JGKB19289.aamtaout02-winn.ispmail.ntl.com@pine.ntlworld.com> > > Just out of interest, why DTD and not XSchema? I would have thought the > > latter were more complete in many respects. >I didn't know about it and I knew XHTML is defined by dtd which I was >interested in. The schema syntax is a little verbose but you get clarity in abundance. I'd be interested in more info on your XHTML validator project. I wonder if anyone's thought of creating a Haskell substitute for the Tomcat,(Oracle|MySQL) web data management system, well, at least the bits that deal with XSQL and XML apps. It's a mystery to me that very few have embraced the idea of a neat clean declarative tool for setting up websites. Paul