- web-devel - Haskell.org

Re: [web-devel] Type-safe URL handling
by Curt Sampson 16 Mar '10

16 Mar '10

On Tue, Mar 16, 2010 at 9:51 AM, Gregory Collins <greg(a)gregorycollins.net>wrote: > This rabbit hole goes pretty deep though; if you're serious about the > bondage and discipline approach you'd want to ensure that you can > check query parameters; i.e. "'/foo' takes a mandatory 'bar' integer > parameter on the queryString and an optional 'sort' parameter which > must be either 'asc' or 'desc'", etc. Which is not at all unreasonable, actually, if you take the approach I sorta-kinda-did with my Ruby system at one point (using regexps to match URIs): if the URL doesn't match the types you need for it, you get a 404. Thus, simplifying immensely for the sake of an example, "/user/show/1312" shows information about user 1312, but "/user/show/13x7" returns a 404. You still have to deal with the problem somewhere else of making sure everything within your system generates valid URLs, though.... cjs -- Curt Sampson <cjs(a)cynic.net +81 90 7737 2974 http://www.starling-software.com The power of accurate observation is commonly called cynicism by those who have not got it. --George Bernard Shaw

1 0

Web projects wiki page
by Michael Snoyman 16 Mar '10

16 Mar '10

Just wanted to give a heads up that a created the wiki page: http://haskell.org/haskellwiki/Web_Projects I put in the ideas that I've already mentioned; please go ahead and augment that list with any other ideas. Also, if someone has a good idea on how to organize the list, go ahead; I'll merge my list into any organizational system someone adds. Michael

3 3

On the state of Haskell web frameworks
by Gregory Collins 16 Mar '10

16 Mar '10

Hi all, Just subscribed, and after reading through the recent traffic on this list in the archives I have a couple of quick comments. First, and I've discussed this with Michael Snoyman at length in private, I agree 100% with Chris Eidhof when he writes "I don't believe that there could be one big framework for everybody." Even getting consensus on what the prerequisites would be is basically impossible. To quote Gour: > Although it might be great framework, I'll be frank to say that > Happstack with all technology that goes along is something which is > either too complicated for me, not practical to be run on shared > hosting (e.g. Webfaction), not documented properly and it belongs to > 'noSQL' which is not for me at the moment. > > That's why I'm interested to discuss possibility to somehow > consolidate Haskell's web frameworks nad provide something which is > good for practical development, does not require VPS to be used, nice > documentation etc. A priori we've reached a fundamental disagreement about first principles -- personally I couldn't give a rat's ass whether the framework I'm using runs well on shared hosting, my focus is on being able to efficiently service heavy loads in a production context. Obviously, on the other side of the coin, being able to run in a CGI process hooked up to Apache is really important to many people. Michael wants to use YAML to define data models: more power to him, but personally the idea of doing that makes me want to vomit. I'm not saying that to disparage him at all, the idea isn't necessarily bad on its own merits: it just isn't for me. Everyone has their own pet preferences. I'm seeing a lot of energy being dedicated to standardizing interfaces, which I suppose is an admirable goal, but to me it's putting the cart before the horse: what's the point of having a standardized adapter when there's nothing worth plugging into it, besides some middleware that your framework should be providing for you anyways? Concentrating too much on interop right now is a waste of time IMO - besides, on the level that it's currently being discussed, that stuff is *easy*: making an adapter between any two of the myriad different web stack implementations (WAI, Happstack, Hyena, CGI, Hack, FastCGI, etc etc etc) is trivial. I doubt there's anyone on this list who couldn't cook up a WAI/CGI gateway in an afternoon. We need pluggable *applications* (blog, CMS, RSS feed generation, administrative panels, forum, wiki, caching, user management, etc) that understand how to talk to each other --- expecting "plug and play" compatibility between frameworks on this level, when there's no consensus on the *primitives*, is a pipe dream. The first framework that cracks this particular nut, in a way that makes it easy and pleasurable for people to build web apps that perform, is going to gain a lot of traction. Code talks. G -- Gregory Collins <greg(a)gregorycollins.net>

6 13

consolidating Haskell's web-framework scene
by Gour 15 Mar '10

15 Mar '10

Hello! I'm (still) Haskell noob learning the language with the help of RWH book and plan to write desktop GUI app (probably with qthaskell). However, there is also need to put together some web sites and I'd be very happy to use Haskell instead of tinkering with Python/Django. You know, once when you get even a small taste for Haskell it's hard to 'go back'. :-) Although it might be great framework, I'll be frank to say that Happstack with all technology that goes along is something which is either too complicated for me, not practical to be run on shared hosting (e.g. Webfaction), not documented properly and it belongs to 'noSQL' which is not for me at the moment. That's why I'm interested to discuss possibility to somehow consolidate Haskell's web frameworks nad provide something which is good for practical development, does not require VPS to be used, nice documentation etc. If we take a look in the Python's neigbourhood, we think something like Django although knowing well that it is quite big community, with lot of docs, books, apps etc., so it's maybe not the best example. However, Alson's yesterday post about leaving Haskell and (probably) leaving Turbinado abandoned (http://www.alsonkemp.com/haskell/reflections-on-leaving-haskell/) made me think to write this post. From his post it is obvious that he faced some walls during his devlopment which he could not overcome. I'm sad that the Turbinado was not more open so that someone can jump in and offer suggestions. Otoh, it was also not documented - docs were promised for quite some time, but nothing happened. Otherwise, the project had some nice objectives...so, let's learn the lessons. Some time ago, Michael posted about Yesod and I read about WAI initiative. He is very responsive and I've already exchanged several emails with him, but being noob for web-development in Haskell I want to learn more and help, according to my skills, that Haskell gets one decent & practical web-framework. The Haskell language itself was created to consolidate fragmented market of different FP languages. Are we ready to follow our 'ancestors' and in their spirit do the same when it comes to web-framework(s)? * Is it WAI & Yesod good start? What the others think? Any further reference you can provide for someone to learn more about web-programming in Haskell? (RWH is not very extensive here.) * I said frameworks because it seems that Happs is in its own category and if you read the comments in the above referenced URL, you'll see that often Happs is labeled as too complex. Sincerely, Gour -- Gour | Hlapicina, Croatia | GPG key: F96FF5F6 ----------------------------------------------------------------

4 7

Re: consolidating Haskell's web-framework scene
by Michael Snoyman 14 Mar '10

14 Mar '10

I was planning on writing a blog post called "call to arms," which would have been something similar to what you said. I agree that there is far too much fragmentation in the community; I debated starting Yesod at all when there were already a number of frameworks out there (Happs, KIbro, Turbinado). However, none of them hit the spot that I was aiming for, so I created it. At the same time, Jinjing came out with Hack, and I tried to go with that. Unfortunately, there are some inherent flaws with Hack (you can review the Hack-discuss mailing list to see some discussions over there), so I started WAI. So it would seem that so far, I've done more fragmentation than consolidation :(. On the other hard, the other frameworks having had much development, Yesod is still active, and it looks like Happstack will be joining WAI, so not all is lost. I am very interested in trying to continue consolidation, but I think aiming for the One True Haskell Framework is a bad idea. Python- the community known for One Way To Do It- can't even consolidate around a single framework, so Haskell- the language of We Can All Write A Monad Transformers Library- doesn't stand a chance. So where can we consolidate? On libraries. I have purposely released a number of the components of Yesod as separate libraries that are available to any framework author (or even someone *not* using a framework). Here are some in particular to look at: wai wai-extra web-encodings clientsession authenticate data-object, data-object-json and data-object-yaml failure and control-monad-failure hack-handler-webkit Some of these packages have very obvious room for future development, and if someone (like Gour) is looking for somewhere to start contributing to the Haskell web community, I would recommend one of the following: authenticate currently supports OpenId 1 and RPXnow. I would like to have authenticate itself support *all* sites that RPXnow does. The first step in that process would be to get authenticate to use the openid package and determine whether a server support openid 1 or 2. From there, Twitter, Facebook, Windows Live support would all be nice. hack-handler-webkit is, IMO, a really cool idea. It allows you to convert any Hack application into a desktop app. It runs simpleserver and then opens up a Webkit window that connects to it. This is much better than simply running the simpleserver and then opening up a webbrowser, because: 1) The program terminates automatically when the web browser closes. 2) You can control menu bars, title bar, etc completely, making it *feel* like a desktop app. 3) You can ensure that all of the functionality you want is present in webkit. Unfortunately, hack-handler-webkit has two problems: 1) It's written for hack instead of WAI. However, this should take all of 5 minutes to fix. 2) It only works on Linux, and even there I don't have any documentation on setting it up. Yesod is still missing a model layer. This is a project that I will most likely be doing myself, since it will need to be designed to integrate very closely with Yesod, but I'll mention some of the design ideas here. (By the way, Chris Eidhof has a package on Github called Basil which looks very interesting here.) 1) I want to use YAML quasi-quoting to define the models. 2) I don't want a super-complex "object relational mapping"; Haskell is already much closer to the relational level than an OO language. 3) Utilize IO thunks (ie, lazy IO loading) so that we don't need to load everything into memory at the beginning. 4) Not tied down to SQL *or* in-memory databases. It should support both of those, but *also* support a system that is usable even in a CGI setup. I'm contemplating now a database that uses multiple directories/files and uses append-only to avoid concurrency issues. Compile-time checking of templates would be great. The Bravo package looks interesting, but I'm a little dubious about the approach used. I think something based on typeclasses might be a bit more nimble. Once again, tight integration with the model system I theoretically design would be nice. So, in summary of a much-too-long e-mail, let's not bother trying to get everyone to agree on One Framework. Happs has its place, Yesod has its place, and I know others are using Loli and probably Kibro. (I'm not sure if anyone every got started with Turbinado.) However, we can raise the bar for *all* packages simultaneously by making a more solid ecosystem of Haskell web packages available that any framework can cherry-pick from. Michael

1 1

Haxr doesn't compile from cabal (HTTP > 4000 breaks it)
by Henning Thielemann 27 Mar '09

27 Mar '09

Most breakage caused by new HTTP package is due to the renaming from Response to Response_String and Request to Request_String. I think it was not a good idea to do that. There could have well be two types named Response from different modules, one with a type parameter and the other one without. Or the parametrized variant could have be named ResponseGeneric or so. That would have allowed packages to work both with version 3001 and 4000.

1 0

Re: [Haskell-cafe] Samples for http package
by Henning Thielemann 27 Feb '09

27 Feb '09

On Fri, 27 Feb 2009, Gü?nther Schmidt wrote: > are there any examples on how to use the current version of the http package? test/get.hs

1 0

[BUG] in WAI definition
by Manlio Perillo 25 Feb '09

25 Feb '09

Hi all. I'm trying to compile the example WAI application, as defined in http://www.haskell.org/haskellwiki/WebApplicationInterface However there are several bugs. 1) The example application returns: return (status, responseHeaders, enumerator) where status is an integer 2) The CgiAdapter expects: (status, reason, respHeaders, output) <- application environ In detail, the type "Application", used in CgiAdapter is never defined. Manlio Perillo

3 10

Re: [Haskell-cafe] HSGI: Haskell Server Gateway Interface
by Felix Martini 08 Feb '09

08 Feb '09

[Original discussion in haskell-cafe: http://www.haskell.org/pipermail/haskell-cafe/2009-February/055270.html] Manlio Perillo: > Here are the problems: > > 1) supported HTTP methods are fixed, since you use a custom data type (Btw. It is not my proposal, Johan Tibell has written it. I'll mail him to notify him about this discussion.) I agree with that. In my own framework prototype i have data HttpMethod = OPTIONS | GET | HEAD | POST | PUT | DELETE | TRACE | CONNECT | Extension String deriving (Eq, Show) > 2) no support for other possible CGI variables > (or simply custom variables: I use the environ dictionary to store > application configuration, and I think it is a great thing). A user dictionary / association list could be useful. A Trie is probably faster than a Map so i am not sure if the Map type should be used. Could also be implemented by the frameworks themselves. > 3) No support for optimized file serving, like with WSGI file_wrapper Would be nice to have provided it is cross-platform. > 4) No support for keeping "complex" state (like database connection) in > the environ. > > I have read some examples with CGI package, where a custom monad > transformer is used. > I'm not sure if this solution is flexible and "scalable". This should be a task for the framework itself. Using a ReaderT or StateT transformer is very common in Haskell. > 5) I can't find documentation about the type of the response. > It is rather clear that it is > (ByteString, [(ByteString, ByteString)], Enumerator) > > but this should be documented somewhere. It's a wiki so feel free to change it or add more documentation. About the enumerator, using it is indeed debatable because it is not immediately obvious how it works, but i haven't seen anything for Haskell that works better. Like other haskellers have said lazy bytestrings with IO is asking for trouble. I have been bitten by it myself and it is hard to debug. Imho lazy bytestrings are only useful when the data generator is a pure function. Regards, Felix

2 1

Re: [Haskell-cafe] Haskell Web Framework
by Marc Weber 26 Jan '09

26 Jan '09

Hi Michael Snoyman, Donnie Jone, I don't think cross posting to web-devel and haskel-cafe is a good idea. Maybe do that but then advice people to either reply to cafe or to web-devel. So I suggest that we continue this discussion on web-devel. First of all there have been some attempts already to provide web frameworks for haskell. If you don't konw WASH yet please do have a look at the examples. I find the idea behind WASH pretty neat. It does also solve parts of the strict XHTML problem. you can only add valid tags and attributes. However it doesn't pay attention to order. (I don't think it was possible that time WASH was written). I've tried to make it better and verify that only valid XHTML is generated. The result is a finate state machine implented using functional dependencies. You can get the code from here git://mawercer.de/vxml.. However while doing so I noticed that this starts turning into a typing hell.. Why? There are some tags which require one or more childs (example : <ul>). So to distinguish both states (empty ul, ul with at least one element which may be closed) you need two different types. Thus you can no longer do myUl = ul $ map (li . show) [1...] My solution was to switch to a weak checking which only allows valid sub tags but does no longer care about order etc. So by now I'd vote for a partial validation only. a total validation isn't worth the effort. But it would be nice to to derive that from some specification (such as XHTML). So maybe have a look at my library and use the weak validation mode. About Ajax: I've developped some Ajax applications beeing written in PHP using MySQL.. In WASH everything is simple: You have one state (it doesn't know about AJAX). From that state you can go on, duplicate it etc. The state is passed to the client using an hidden input. So there is not that much you have to care about. But you can't write that much interaction easily either. When starting to write a web application (say a web shop).. it would be best if the client page keeps a state knowing about the basket and its content as well. And if you start implenting fancy features such as drag and drop I'm no longer sure which is the best way to handle this "client" state. I even don't know wether it can be abstracted on server side (using any language).. I'll watch you, keep posting to this list about your progress. Comments about the blog post (http://blog.snoyman.com/2009/01/25/haskell-web-framework/) Maybe the first step is writing down differences between existing haskell web frameworks. Probably the haskell wiki would be a good place to start. Another first step might be writing kind of abstraction so that an application can use either HAppS or apache or (fast)-CGI etc.. Encrypted cookies :-) Nice idea.. However this does mean a lot more traffic, doesn't it? It also depends on your storage enginge. If you have once keeping stuff in memory this won't hurt that much. But you're right. I'll think about that option About 13.: We should be able to simply specify the algorithm necessary to calculate an age from a birthday, and the framework will convert this into both client- and server-side code There is already a haskell -> JS converter.. However this will cause a lot more traffic. And if you have many users only loading the front page .. How do you want to utilize the power of existing script frameworks (eg Mootools) ? Should the engine be aware about those? What about CSS abstraction ? I mean ie6 does read some CSS properties quite different.. What about JS automatic compression (maybe even rewriting names to shorter ones)? Sincerly Marc Weber

2 1