On 6/2/08 10:21 AM, Don Stewart wrote:

aditya_siram:

...

I am building a web-app that, in broad strokes, allows a leader to assign tasks to team members and allows team members to accept/reject/pick tasks that they want to do.

I really like Haskell and I would like to use it to implement the solution. Are frameworks like Happs ready? Not so much in terms of documentation, but in functionality and stability.

HAppS is nice (see hpaste.org for example, which is nice and simple, and has been running for over a year).

Another nice option in Haskell is using something like HStringTemplate or the xhtml combinators with fastcgi hooked into GHC's concurrency mechanisms.

If you're interested in the background of rolling your own web stuff, I like Paul Brown's description of building perpubplat here: http://mult.ifario.us/t/blog HTH, Keith

A new version of happs was written on a Monday a couple of months ago, using fastcgi and takusen. We're running it at galois, and you can find the code on code.haskell.org/hpaste. So not quite what you wanted, but another data point. -- Don tphyahoo:

Note however that hpaste runs off an earlier version of HAppS, which has changed radically from v8 to v9.

I seem to remember discussion of porting hpaste to the latest HAppS as a demo app... are there still plans to do that?

Thomas.

2008/6/2 Don Stewart :

...

aditya_siram:

...

I am building a web-app that, in broad strokes, allows a leader to assign tasks to team members and allows team members to accept/reject/pick tasks that they want to do.

I really like Haskell and I would like to use it to implement the solution. Are frameworks like Happs ready? Not so much in terms of documentation, but in functionality and stability.

HAppS is nice (see hpaste.org for example, which is nice and simple, and has been running for over a year).

Another nice option in Haskell is using something like HStringTemplate or the xhtml combinators with fastcgi hooked into GHC's concurrency mechanisms.

You can find *many* more things here,

http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Network http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Web _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Ah yes, the url was incorrect. Well spotted. tphyahoo:

note to the curious that this is a git and not a darcs repo

git clone http://code.haskell.org/hpaste.git

thomas.

2008/6/3 Don Stewart :

...

A new version of happs was written on a Monday a couple of months ago, using fastcgi and takusen. We're running it at galois, and you can find the code on code.haskell.org/hpaste. So not quite what you wanted, but another data point.

-- Don

tphyahoo:

...

Note however that hpaste runs off an earlier version of HAppS, which has changed radically from v8 to v9.

I seem to remember discussion of porting hpaste to the latest HAppS as a demo app... are there still plans to do that?

Thomas.

2008/6/2 Don Stewart :

...

aditya_siram:

...

I am building a web-app that, in broad strokes, allows a leader to assign tasks to team members and allows team members to accept/reject/pick tasks that they want to do.

I really like Haskell and I would like to use it to implement the solution. Are frameworks like Happs ready? Not so much in terms of documentation, but in functionality and stability.

HAppS is nice (see hpaste.org for example, which is nice and simple, and has been running for over a year).

Another nice option in Haskell is using something like HStringTemplate or the xhtml combinators with fastcgi hooked into GHC's concurrency mechanisms.

You can find *many* more things here,

http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Network http://hackage.haskell.org/packages/archive/pkg-list.html#cat:Web _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Duncan Coutts wrote:

On Tue, 2008-06-03 at 10:23 -0700, Don Stewart wrote:

...

A new version of happs was written on a Monday a couple of months ago, using fastcgi and takusen. We're running it at galois, and you can find the code on code.haskell.org/hpaste. So not quite what you wanted, but another data point.

That's very interesting. I hope we will also see a version with the same feature set implemented with the latest HAppS. It would give an interesting comparison of the web frameworks to see the same app implemented in both.

I haven't looked at that particular version, but when I last looked at web frameworks, I was somewhat disappointed. HAppS seemed to have little documentation on the current version anyhow, and especially little coverage on what to do if your app revolved around serving data from an existing SQL database or other data source rather than its own. 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. My needs for that project were not complex, the layout was not very important, and the presentation never changes (only the business logic). So I understand that my needs may have been opposite from what most people face. -- John

s.clover:

...

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?)

Sterling, Would you like to add some text on hvac and your other web libs to our web programming wiki/faq, http://haskell.org/haskellwiki/Practical_web_programming_in_Haskell Ideally, in a few months time, with enough additions, the full story will be covered on this wiki page, and it will be a great boon to developers wanting to work in Haskell, in this hot area. -- Don

On 2008 Jun 4, at 22:30, Paul L wrote:

The server is then very much like a VM or an interpreter of an embedded language, with execution stacks entirely encoded and stored in each HTML page sent to the user and back from the user as an encoded URL or form data. So the server is entirely stateless.

Mmm, if any of that HTML-stored state is sensitive server information, this becomes a problem. (E.g. can I trick your application into thinking I'm an admin and then go starting/stopping processes, changing passwords. etc.?) You need to use extra care if anything sensitive is put where the client can munge it. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Paul L wrote:

Pardon me to hijack this thread, but I have an idea to build a different kind of Web Framework and am not sure if somebody has already done it.

The idea is to take REST further: every HTML page you see is a program in its running state (as a continuation monad). Each click on its link or form submission is seen as feeding data to resume its continuation.

So instead of writing a server-side program that responds to many CGI calls, you write a single ordinary program that describe the application logic, which during its execution gets represented as a HTML page and interpreted by the server.

WASH/CGI has something in that direction. I don't know a short introduction, but have a look at sections 4 and 8 of the implementation notes http://www.informatik.uni-freiburg.de/~thiemann/WASH/draft.pdf The basic idea is that displayForm in a CGI-script like main = do password <- displayForm $ (label "Enter password" <-> editbox) ... displays a HTML-page to the client, "waits" for a response and then resumes execution. It does not actually wait, but captures the continuation in the transmitted HTML page, for instance by saving a log of the previous events. This is related to [MonadPrompt], which has a similar purpose, and to [Unimo], which is pretty much the same but from the slightly different viewpoint of implementing any monad directly from its operational semantics. [Unimo]: Chuan-Kai Lin. Programming Monads Operationally with Unimo. http://web.cecs.pdx.edu/~cklin/papers/unimo-143.pdf [MonadPrompt]: Ryan Ingram. http://hackage.haskell.org/cgi-bin/hackage-scripts/package/MonadPrompt Regards, apfelmus

Thank you guys for all the good references! To address a few concerns with this approach: 1. By stateless I don't mean to strip away any persistency. The program can access file storage or DBMS just like any ordinary I/O operation. 2. If we take it to the extreme side, the entire program including its bytecode and all runtime data are in the page itself. The server is really just a VM to execute it to the next step. Security is a concern, but with proper cryptographic measures (e.g., a digitally signed hash for integrity check) I don't think it's any less secure (or insecure?) than existing web application frameworks. 3. The extreme scenario is perhaps not very practical, but still a nice abstraction and a start point to optimize. For example, program bytecode can just be its version number, which is matched against a code repository on the server side to retrieve. 4. As for cryptic URIs, well, I don't think it's a real problem. URIs meaningful to the users are often just starting point for a task flow. URIs that refers to somewhere in the middle of a task flow are often not meant to be readable anyway. Per-login-session data can be stuffed into the cookies and remain invisible. Any sizeable chunk of data should be handled as form data anyway. So what's left are the small pieces that gets attached to URIs, they are pretty harmless if you ask me. 5. I for one do not think multi-user scenario is that much harder as I was a MMOG developer. Sure, transactional behavior should be in place to ensure correctness, but user to user interactions aren't very complex for web applications to begin with. If they are, probably web aren't the most suitable platform. I took a quick look at the WASH paper, and the iData paper, and visited Seaside's website. They are all very relevant, which at least says something about a common vision. I'll just quote it from Seaside's about page: "Unlike servlet models which require a separate handler for each page or request, Seaside models an entire user session as a continuous piece of code, with natural, linear control flow." -- Regards, Paul Liu Yale Haskell Group http://www.haskell.org/yale