<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><div>I´m working in a web application rather than a web framework. But I sometimes think about how a complete web application server should be. For my case, I don´t care about the presentation, because HSP is more than enough. However, I need active-active clustering, distributed transactions and workflows. I have created the module Workflow for the latter. For the former, I developped TCache, that is a transactional cache using STM, with configurable persistence. It´s like hibernate for Java and (the data part of) Rails for Rubi. Now I´m working in a extension of TCache with distributed transactions and remote clustering with some additonal interesting characteristics.</div>
</div></div></blockquote><div><br>That all sounds like something that would fit very nicely into this framework that I'm addressing. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div><div>My own view about haskell and Web applications is that something like " a web framework" is not in the philosophy of Haskell. What is in the philosophy of Haskell is the creation of modules that the people can combine to create their own web frameworks.</div>
</div></div></blockquote><div><br>I agree to a certain extent. If you look at the code that I've written so far, it's in "layers." The bottom layer defines a Request and Response object, defines a service as "Request -> IO Response", and a server as something as essentially "Service -> IO ()". The next layer is a controller which is itself a service. View details are built on top of this.<br>
<br>In your case, you could bypass all the controller logic if you like and simply deal with the server definition. You would get the advantage of having your app work as a standalone server, a CGI program, FastCGI, or anything else that people write adapters for. Someone else might decide to use the the controller and ignore the specialized view code (they really like dealing with straight Strings perhaps).<br>
<br>However, I think we should develop a full stack so that it is available for those that want it. From my Django experience, I must say that very few things are cooler than calling a script which automatically generates all the boilerplate code inherent in every web app. I think those features should be available to those who want it (even if it's not in the spirit of Haskell), while those who want to treat the "framework" as a set of libraries need not been hindered by the extra features.<br>
<br>Michael<br>
</div></div>