Alright, so web-devel doesn't seem interested in moderating my message, so I'll just break it up into two chunks: 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.

And part 2: 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.

On Mon, Mar 15, 2010 at 9:07 AM, Dmitry Belayev wrote:

Compile-type checking can be very helpful and it is Haskell's strong side.

But what about hot code swapping? In working web application it is often convenient to update some part of application without disturbing connected users. It's strong side of Erlang, but what about Haskell?

That's definitely a good point. My current deployment uses lighttpd/CGI to server the application, along with a development system running on 3000. Here's my workflow: 1) Develop on local system using simple-server. 2) Push changes to development system. Who cares about a little downtime there. 3) When everything works, pull changes into the production repo. 4) Compile everything with -Wall -Werror. 5) Copy templates, static files and CGI binary in one fell swoop to the production directory. So this is really a solution outside of Haskell. I believe Turbinado used some features for dynamically compiling code, but I prefer this kind of approach in general. If I was during a standalone server approach, one possibility for production deployment might be: 1) Run the production server on port 3001 (or anything else). Set up iptables to forward port 80 to port 3001. (I do this already). 2) When I want to make a production change, start a *new* production server on port 3002. 3) Adjust iptables to port forward to 3002. 4) Next time around, switch back to 3001. For the record, I think iptables forwarding is probably the safest way to run an application on a privileged port. Michael Snoyman wrote:

...

And part 2:

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

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