Announcing Happstack: A fork of HAppS

[Matthew Elder]

Attention HAppS Enthusiasts!

I am reaching out to find other like-minded individuals who want to develop, test, and use HAppS but feel a bit weary that the project is losing momentum. Alex Jacobsen has done a lot of work to build the coherent platform that exists today -- but it still is wanting of some love.

In particular:

1. Only a few people can commit to the HAppS codebase
2. Documentation is lacking
3. Test coverage is lacking
4. The code needs a lot of cleanup!

So what are we to do now? We can go on our merry way and allow it to silently slip away. The project will eventually be superceded by other Haskell frameworks like Turbinado which are not nearly as innovative -- and interest will wane. The heyday of databases will continue for another decade, and we can all cuddle up to our loved ones and have peace of mind. Then we will always ask ourself, what if HAppS and more importantly MACID would have changed the landscape of web applications as we know it?

What if instead we pick up the torch and keep the flame alive? What if we pick up our keyboards and hack like we've never hacked before, collaborate like we've never collaborated before? What if the Java Despots and the Python Conglomorates fall, and fortune 500 companies pound down our doors with job opportunities? Well, that could happen, maybe...

So what are we waiting for? Let's band together and start afresh with the HAppS vision and mold it into something truly formidable! What I propose:

1. Consolidate the code that makes happs up into one repository and adopt a much more liberal development strategy.
2. Identify our own strengths and share the load in order to make HAppS the best it can be!

I am kicking off this project in the hopes that all who enjoy haskell and want to bridge the gap between the hohum world of web programming and lambdas to make the most glorious app server ever!

I am forking the HAppS project under the banner of Happstack in the hope that all who are able and willing will join me! Please join us on #happs when you have the time, or simply respond to this thread on the mailing list. We will be giving out commit rights, collaborating, and getting to know each other in general.

For more information, please see the newly minted website and blog.

Your partner in the new revolution,
Matthew Elder

[Simon Michael]

Hi Matthew, thanks for this initiative. It sounds good, but it would be
good to hear from the current HAppS developers as well. Were you able to
reach them ? Will we end up with competing HAppSen ?

[Matthew Elder]

Yes, the only active developer that I know of is Lemmih. I ran the idea by him and he seems to be supportive of it. I'm sure given a day or two we will hear what everyone has to say about this :)

The idea isn't to totally go off the deep end but to revive the development of the current project. Really all we are doing initially is changing the logistics of the current root repository so patches can flow again. There is always the possibility of integrating patches backwards -- if we don't hear from Alex though, it will end up being a fully fledged fork.

What is HAppSen?

--
Matthew Elder
Mr. Handsome

[Lemmih]

There are no current HAppS developers. The project has been orphaned
(this happened about a year ago).

--
Cheers,
Lemmih

[Eelco Lempsink]

Hi Matthew,

On 22 jan 2009, at 00:45, Matthew Elder wrote:
> I am forking the HAppS project under the banner of Happstack in the
> hope that all who are able and willing will join me!

Great initiative, very brave! ;) I hope we figure out a nice way of
HAppS and Happstack to coincide without wasting energy on competing.
I'm certainly interested in how this will work out, but either way,
it's very nice that more time is donated to making HAppS/Happstack a
success.

--
Regards,

Eelco Lempsink

[Simon Michael]

Glad we got that clear. :) Is there any chance we can keep calling it
happs then, and take over or shut down the old site ?

[Matthew Elder]

Taking over the old site is not an option right now, unless Alex Jacobson shows up. He is the one with the keys.

On Wed, Jan 21, 2009 at 4:43 PM, Simon Michael <si...@joyful.com> wrote:

Glad we got that clear. :) Is there any chance we can keep calling it
happs then, and take over or shut down the old site ?

[tphyahoo]

Excellent!

I fervently hope this is a successful catalyst for getting happs de-
orphaned, and applaud matt for stepping up to the challenge.

Thomas.

[Matthew Elder]

Wooo. OK, let me know if you need help with the patch-tag launch.

[Michael Litchard]

Hi. I'm nearly a complete haskell newbie (I'm only on chapter 4 of
RWH). HAppS inspired me to be interested in web programming, which I
was rather bored by until now. I want to contribute however a newbie
like me can. So let me know what I can do.

Michael Litchard

[MightyByte]

Michael,

In general, HAppS is not a good project for Haskell newbies. It makes
significant use of more advanced Haskell features such as template
haskell. Probably the best place to start is in the documentation
realm. But if you put some serious effort into learning Haskell and
HAppS, you should be able to make significant progress.

MightyByte

--
Timid men prefer the calm of despotism to the tempestuous sea of Liberty.
-- Thomas Jefferson

[Matthew Elder]

Michael,

While I would tend to agree with Michael in the general sense. If you are a glutton for punishment (or just like a good challenge) -- you could always try building something simple with the development code. Information on how to get the code is at http://happstack.com/develop.html . Report any bugs you find or problems you run into -- a newbie perspective isn't necessarily a bad thing as I would like the project to be within reach of mere mortals :)

Thanks for your enthusiasm!

[Eelco Lempsink]

Luckily, there are still developers actively developing _with_
HAppS ;) The boost of interest gitit has generated certainly helped.
Too bad nobody seems to have known about the orphaning, but I'm sure
we can gather a nice group of developers to re-energize HAppS!

--
Regards,

Eelco Lempsink

[MightyByte]

Michael,

I would agree with Matthew. Definitely don't let my previous
statement dissuade you from using HAppS do develop web pages. I
started trying to use HAppS as a Haskell newbie as well. I'm just
saying that it will be harder to make meaningful contributions to the
HAppS codebase as a newbie.

[fiddlosopher]

I think this is a great idea. I wasn't even aware that HAppS was
orphaned, but I've been wishing some things would get cleaned up.
Here's a small list of suggestions:

* HAppS-Server currently depends on HAppS-State, but only because of
a couple of trivial functions. I think it would be good to make
HAppS-Server independent of HAppS-State. Future versions of gitit,
for example, will use HAppS-Server but not HAppS-State.

* It would be good if non-essential stuff (like Facebook) could be
moved out of HAppS-Server, perhaps into a HAppS-Extras module.
It's currently impossible to compile HAppS-Server on my VPS without
manually removing the Facebook module, because it takes so much
memory to compile it.

* Currently HAppS-Server doesn't provide support for character
encodings.
Gitit uses some ugly workarounds here. There are some useful
suggestions at http://article.gmane.org/gmane.comp.lang.haskell.cafe/49700.

Best,
John

> website<http://happstack.com/>and
> blog <http://blog.happstack.com/>.

[stepcut]

I would definitely like to see the Facebook stuff moved out, if only
because it takes so long to compile that module. Also, I am possibly
working on a competing Facebook module for HAppS ;)

- j

On Jan 21, 7:58 pm, fiddlosopher <fiddlosop...@gmail.com> wrote:
> I think this is a great idea.  I wasn't even aware that HAppS was
> orphaned, but I've been wishing some things would get cleaned up.
> Here's a small list of suggestions:
>
> * HAppS-Server currently depends on HAppS-State, but only because of
>   a couple of trivial functions.  I think it would be good to make
>   HAppS-Server independent of HAppS-State.  Future versions of gitit,
>   for example, will use HAppS-Server but not HAppS-State.
>
> * It would be good if non-essential stuff (like Facebook) could be
>   moved out of HAppS-Server, perhaps into a HAppS-Extras module.
>   It's currently impossible to compile HAppS-Server on my VPS without
>   manually removing the Facebook module, because it takes so much
>   memory to compile it.
>
> * Currently HAppS-Server doesn't provide support for character
> encodings.
>   Gitit uses some ugly workarounds here.  There are some useful

>   suggestions athttp://article.gmane.org/gmane.comp.lang.haskell.cafe/49700.

[chessguy]

I might be interested in helping out with this project, but only if
it's well-organized. I have limited time to contribute, and I want it
to be coding, not dealing with organizational matters :)

[Creighton Hogg]

On Wed, Jan 21, 2009 at 8:14 PM, stepcut <jer...@n-heptane.com> wrote:
>
> I would definitely like to see the Facebook stuff moved out, if only
> because it takes so long to compile that module. Also, I am possibly
> working on a competing Facebook module for HAppS ;)

Why _is_ the Facebook module in HAppS-Server to begin with?

[Zachary Michaels]

Hi Michael,

I'm in kind of the same boat as you, and I say we rise to the challenge. I know that HAppS will probably be difficult for people like us, but what better way to learn than to dive in head first? What say we start a (google?) group for Haskell newbs that are interested in exploring Happs with an eye toward hacking the source? That way we don't get in the way of the people that already know what they're doing, but we get to join in the fun. Just a thought...

Let me know,
Zach

[Artyom Shalkhakov]

Hello,

2009/1/22 Matthew Elder <ma...@mattelder.org>:

>
> 1. Only a few people can commit to the HAppS codebase
> 2. Documentation is lacking
> 3. Test coverage is lacking
> 4. The code needs a lot of cleanup!
>

I would like to contribute the code and documentation.

I don't know HAppS very well ATM, but I think it's fixable. :)

Cheers,
Artyom Shalkhakov.

[Matthew Elder]

Here's a small list of suggestions:

* HAppS-Server currently depends on HAppS-State, but only because of
 a couple of trivial functions.  I think it would be good to make
 HAppS-Server independent of HAppS-State.  Future versions of gitit,
 for example, will use HAppS-Server but not HAppS-State.

Definitely agree with creating cleaner abstractions
 

* It would be good if non-essential stuff (like Facebook) could be
 moved out of HAppS-Server, perhaps into a HAppS-Extras module.
 It's currently impossible to compile HAppS-Server on my VPS without
 manually removing the Facebook module, because it takes so much
 memory to compile it.

Also one of my target items.
 

* Currently HAppS-Server doesn't provide support for character
encodings.
 Gitit uses some ugly workarounds here.  There are some useful
 suggestions at http://article.gmane.org/gmane.comp.lang.haskell.cafe/49700.

I don't know enough about this, but if you can submit a patch then we can surely test it!
 

Best,
John

[Matthew Elder]

I might be interested in helping out with this project, but only if
it's well-organized. I have limited time to contribute, and I want it
to be coding, not dealing with organizational matters :)

I definitely agree with this. I also have limited time and want to focus on "getting work done". If anyone has suggestions on how we can divvy up work I am all ears. I was considering a simple TODO list for starters.

TODO:
- Put facebook stuff into separate module (extra or contrib)
- Clean up dependencies between server and state
- Character encoding sophistication
- Name resolution crash bug (I have a fix for this that is not committed)
- Fix compiler warnings
- Fix deprecated pragmas to use new LANGUAGE syntax
- remove dead code (there are some modules which are not included anywhere internally)
- document all exported functions in the various modules
- write functional tests for each module which tests basic semantics (hunit or quickcheck gurus?)
- problem with cookies not working (there is a fix for this but needs to be a patch which can be put in the main repository at the package level)
- ... help me fill in some blanks here so we can flesh out this initial brainstorm

[Matthew Elder]

Good question, this is obviously code bloat. I think that with enough effort, we can cut this codebase in half while retaining the same basic functionality. This is ambitious, we need to defend against regressions (hence the need for at least some tests).

While we're at it, I want to define some milestones so perhaps you all could elaborate on some directions you'd like to see happs take?

[Matthew Elder]

Zachary, I personally don't see any problem with "newbie" posts on this mailing list. Just keep them in their own thread and on topic. The good part about this would be that other newbies can look at the troubleshooting steps you went through.

My 2c.

[Matthew Elder]

Well artyom, you can probably understand how some of the happs stuff works by reading the code for happstutorial.com maybe you can start there? When you get an understanding any module-level and function-level documentation blocks would be gladly accepted to the project. Be sure to read up on haddock so you know the syntax.

[Andrea Vezzosi]

The first move should be putting up a bugtracker so we can have such
TODO lists in a central place, and it's easier to see what needs to be
done for a contributor.
A wiki with an introduction to the codebase or where we can describe
larger proposals would be useful, too.

[Matthew Elder]

Yeah, I was thinking about the bugtracker. patch-tag will eventually
support both wiki and issue tracking but probably we need something in
the interim. Perhaps we can simply use the google code system for now?
It has basic issues/bugs and wiki. Thomas Hartman is graciously
hosting happstack.com right now but I don't want to utterly annihilate
his virtual private server with anything too heavy... Is there any
freely available services for open source projects that are good for
these types of things?

On Jan 21, 10:58 pm, Andrea Vezzosi <sanzhi...@gmail.com> wrote:
> The first move should be putting up a bugtracker so we can have such
> TODO lists in a central place, and it's easier to see what needs to be
> done for a contributor.
> A wiki with an introduction to the codebase or where we can describe
> larger proposals would be useful, too.
>

[Eelco Lempsink]

On 22 jan 2009, at 08:03, Matthew Elder wrote:
> Yeah, I was thinking about the bugtracker. patch-tag will eventually
> support both wiki and issue tracking but probably we need something in
> the interim. Perhaps we can simply use the google code system for now?
> It has basic issues/bugs and wiki.

I think Google's stuff is relatively good. As a matter of fact, there
already is a bug tracker for HAppS set up at http://code.google.com/p/happs/issues/list
Some of the issues on the list are still relevant, but it needs a
bit of cleanup.

--
Regards,

Eelco Lempsink

[Pierre-Edouard PORTIER]

Hi !
I'm a user of HAppS. I develop a digital library application for modern manuscripts. The server side runs on HAppS. I would be interested in participating.
Cheers,
pidou

2009/1/22 Matthew Elder <ma...@mattelder.org>

[Hugo Gomes]

Nice,

here goes some strange ideas that i've been hatching up:

- patching happs so it uses the new 4000.x http package

- ffi for sendfile (while maintaining windows usability)

- http 1.1 gzip support (through some sort of file caching, readerT perhaps ?)

it would be great if it could be faster than apache :)

On Wed, Jan 21, 2009 at 11:45 PM, Matthew Elder <ma...@mattelder.org> wrote:

Attention HAppS Enthusiasts!

I am reaching out to find other like-minded individuals who want to develop, test, and use HAppS but feel a bit weary that the project is losing momentum. Alex Jacobsen has done a lot of work to build the coherent platform that exists today -- but it still is wanting of some love.

In particular:

1. Only a few people can commit to the HAppS codebase
2. Documentation is lacking
3. Test coverage is lacking
4. The code needs a lot of cleanup!

[Bas van Dijk]

On Thu, Jan 22, 2009 at 8:03 AM, Matthew Elder <ma...@mattelder.org> wrote:
> Is there any freely available services for open source projects that are good for
> these types of things?

I would vote for http://community.haskell.org/

It provides code and website hosting, issue tracking with trac,
mailing lists using mailmain and ssh access.

Many Haskell projects use it so most Haskell hackers (potential
Happstack developers) should be used to it.

regards,

Bas

[Lally Singh]

I'm up to contribute -- just learned haskell last month :-)

But, I think what we'll need is some community organization. Perhaps
nothing formal, but a good number of people who have talked enough
between each other to hold the whole thing together.

Maybe an IRC party?

--
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

[Mike South]

On Wed, Jan 21, 2009 at 7:14 PM, Matthew Elder <ma...@mattelder.org> wrote:
> Michael,
>
> While I would tend to agree with Michael in the general sense. If you are a
> glutton for punishment (or just like a good challenge) -- you could always
> try building something simple with the development code. Information on how
> to get the code is at http://happstack.com/develop.html . Report any bugs
> you find or problems you run into -- a newbie perspective isn't necessarily
> a bad thing

It's not just that it's not a bad thing, it's an absolutely critical
ingredient. The best thing that can happen to a project like this is
wide adoption. The biggest barrier to wide adoption is how hard it is
to start using. The biggest difficulty with lowering the barrier to
entry is that people involved in the project naturally get very
comfortable and familiar with it and can no longer remember what it
was like to come at it cold. Whether that means working on the code
itself for the first time or building a project with it, only a newbie
can have the critical newbie perspective.

My advice would be for you to note _everything_ that confused you as
you were getting going (this is hard to do, because (a) you want to
get on with your project (b) your mind tends to throw away things that
it doesn't consider important, like any blind alley you went down,
because it's useless knowledge (c) we're socially programmed to cover
rather than expose our ignorance. But you only have your ignorance
once, so you need to get all you can from it.

mike

[Gwern Branwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Thu, Jan 22, 2009 at 5:11 AM, Hugo Gomes wrote:
> Nice,
>
> here goes some strange ideas that i've been hatching up:
>
> - patching happs so it uses the new 4000.x http package
>
> - ffi for sendfile (while maintaining windows usability)
>
> - http 1.1 gzip support (through some sort of file caching, readerT perhaps
> ?)
>
> it would be great if it could be faster than apache :)

Out of curiosity, by http gzip support - do you mean simply gzipping
the HTML text and plopping on a gzip header?

As it happens, I believe I just yesterday was working out how to do
that with Gitit. The ultimate solution turned out to be fairly simple,
and looked like this:

gzip :: String -> Response
gzip = setHeader "Content-Encoding" "gzip" . toResponse . compress .
B.fromChunks . return . fromString

instance ToMessage B.ByteString where
toContentType _ = Data.ByteString.Char8.pack "text/plain"
toMessage a = a

(fromString is utf8-string's String->ByteString utf8-preserving
conversion, and compress is from zlib; the stuff in between is to
change fromString's strict ByteString to compress's lazy ByteString.)

- --
gwern
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkl4keMACgkQvpDo5Pfl1oIiQACdF2aoW7Th+gUwzprH+Yz0a4yD
3rcAn0tcl5JJmcDt2SR/uhrMYpygQSzA
=d631
-----END PGP SIGNATURE-----

[David Bergman]

I think any attempt at a MACID framework with a goal to actually not only show (i) a unique model of operation for (web or other) servers and (ii) show how cool Haskell is, both of which HAppS achieved, but also to provide a real, tangible solution for real applications (one can get some inspiration from my friend's ErlyWeb Erlang-based framework) will require - or at least lead to - a totally new code base, due to various factors, not least sociological ;-)

What I said above is that an attempt to build something more than a showcase (similar to the Scala-based "lift") will require a team of at least 3 building code from scratch, being inspired heavily by, and even borrowing (with consent...) from, HAppS.

/David

[Hugo Gomes]

Nice,

what i meant by was something like implementing the full http rfc as described in:

http://www.faqs.org/rfcs/rfc2616.html

the gzip is specified in section 14.11 Content-Encoding.

I think it would be a great nice feature, to exploit lazyness and some sort of caching mechanism to do it without much cpu effort, since the bottleneck in web pages is still on the network side.

diff --git a/Gitit.hs b/Gitit.hs
index dc96add..7da85f5 100644
--- a/Gitit.hs
+++ b/Gitit.hs
@@ -48,6 +48,7 @@ import Text.Pandoc.Shared (HTMLMathMethod(..), substitute)
 import Data.Char (isAlphaNum, isAlpha, toLower)
 import Control.Monad.Reader
 import qualified Data.ByteString.Lazy as B
+import Data.ByteString.Char8 (pack)
 import Network.HTTP (urlEncodeVars, urlEncode)
 import System.Console.GetOpt
 import System.Exit
@@ -59,6 +60,7 @@ import System.IO.Unsafe (unsafePerformIO)
 import Network.Socket
 import Network.Captcha.ReCaptcha (captchaFields, validateCaptcha)
 import Data.FileStore
+import Codec.Compression.GZip (compress)

 gititVersion :: String
 gititVersion = "0.4.1.3"
@@ -1008,7 +1010,16 @@ formattedPage layout page params htmlContents = do
                   T.setAttribute "messages" (renderHtmlFragment htmlMessages) $
                   T.setAttribute "content" (renderHtmlFragment htmlContents) $
                   templ
-  ok $ setContentType "text/html" $ toResponse $ encodeString filledTemp
+  let dogzip = True
+  if dogzip then ok $ setContentType "text/html" $ gzip filledTemp
+   else ok $ setContentType "text/html" $ toResponse $ encodeString filledTemp
+
+gzip :: String -> Response
+gzip = setHeader "Content-Encoding" "gzip" . toResponse . compress . B.fromChunks . return . fromString
+
+instance ToMessage B.ByteString where
+    toContentType _ = Data.ByteString.Char8.pack "text/plain"
+    toMessage a = a

 -- user authentication
 loginForm :: Html
diff --git a/gitit.cabal b/gitit.cabal
index e106eaa..8c5dc55 100644
--- a/gitit.cabal
+++ b/gitit.cabal
@@ -49,7 +49,7 @@ Executable           gitit
                     network, old-time, highlighting-kate, bytestring,
                     utf8-string, HAppS-Server >= 0.9.3 && < 0.9.4,
                     SHA > 1, HTTP, HStringTemplate, random, network >= 2.1.0.0,
-                     recaptcha >= 0.1, filestore, datetime
+                     recaptcha >= 0.1, filestore, datetime, zlib
  if impl(ghc >= 6.10)
    build-depends:   base >= 4, syb
  ghc-options:       -Wall -threaded

[Creighton Hogg]

Hello,

The attached should be a patch to move the facebook module & the two
modules that depend on it into a new directory called HAppS-Extras.
Unless I messed up the darcs recording, this should work. The cabal
file for HAppS-Extras isn't optimal yet & could probably be pruned.

[tphyahoo]

Basically because it was in there when the project got orphaned, I
think. IIRC taking the facebook stuff out of the core code has been on
the todo list (of the google code project owned by alex) for a while.
Just never got done.

[tphyahoo]

Basically because it was in there when the project got orphaned, I
think. IIRC taking the facebook stuff out of the core code has been on
the todo list (of the google code project owned by alex) for a while.
Just never got done.

On Jan 21, 7:07 pm, Creighton Hogg <wch...@gmail.com> wrote:

[Creighton Hogg]

I'm including a patch to convert the HAppS-Server & HAppS-Data
packages to use the proper language pragma. IxSet & State were
already fine.

[Gwern Branwen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Ah, so you meant with all the flourishes, like supporting compress and
the compression-level indicators and alternative spellings like
x-gzip.

And I'd note that zlib's compress function does produce a lazy
bytestring, so that's covered I think. (It works pretty well in my
Gitit tests. Noticeably reduces the size of the page and thus the time
it takes to transfer, even on a localhost - so presumably over the
Internet would be even better.)

- --
gwern

- ---------- Forwarded message ----------
From: Hugo Gomes
Date: Thu, Jan 22, 2009 at 10:58 AM
Subject: Re: Announcing Happstack: A fork of HAppS
To: HA...@googlegroups.com

Nice,

what i meant by was something like implementing the full http rfc as
described in:

http://www.faqs.org/rfcs/rfc2616.html

the gzip is specified in section 14.11 Content-Encoding.

I think it would be a great nice feature, to exploit lazyness and some
sort of caching mechanism to do it without much cpu effort, since the
bottleneck in web pages is still on the network side.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEAREKAAYFAkl4rnsACgkQvpDo5Pfl1oIKSACgi0I2pw+BGmII4shcs1ao7+EJ
aroAoIvTE/LKQ4zGBLQWcGkGjlzo1jWY
=J1ND
-----END PGP SIGNATURE-----

[Matthew Elder]

I like this idea, let me see the patches :)

[Gwern Branwen]

On Thu, Jan 22, 2009 at 12:43 PM, Matthew Elder <ma...@mattelder.org> wrote:
> Working Code is better than theoretical code . . . I guess for full RFC
> support we need to consider the semantics of how and when gzip would be
> enabled.

I think the semantics are relatively simple: if the client says it can
handle it, always gzip it. My implementation is UTF8-friendly, so it
doesn't cost us anything there, and browsing even small pages on my
local wiki shows speedups - and small pages on the hard disk are the
pages on which gzip should be a pessimization if it's ever going to be
one.

If the client sends a strange header that my code doesn't see as a
valid gzip-supporting-claim, then happs will do as it always does and
send text, so false negatives, if you will, are not an issue. (False
positives are a bigger deal, since a client which can't handle gzip
would display a gzip'd page as garbage, but I don't see how false
positives could arise except if the client lies. In which case the
client deserves garbage.)

I suppose depending on the zlib library may be an issue, but
cabal-install depends on zlib, and I can't imagine anyone installing
happs or gitit manually... so it's nearly a free dependency.

--
gwern

[Matthew Elder]

Can you integrate it into the http server code? I would love to see a
patch. Again, not concerned with rfc's as much as I am a working
product :)

On Jan 22, 10:38 am, Gwern Branwen <gwe...@gmail.com> wrote:

[David Fox]

It would be very helpful if the components were split into separate
darcs repositories the way the ones at happs.org were. This makes it
easier to use one component without all the others, or more
importantly to pull patches into one component without pulling them
into all the others.

David Fox

[Matthew Elder]

> It would be very helpful if the components were split into separate
> darcs repositories the way the ones at happs.org were. 

I agree this is helpful for the end user, but most end users will not use darcs -- they will use the cabal packages.

 

> This makes it
> easier to use one component without all the others, or more
> importantly to pull patches into one component without pulling them
> into all the others.

I don't fully see the use case for this. The repository is mainly for developers, and as a developer I find putting all the packages in one repository more convenient.

[Gwern Branwen]

On Thu, Jan 22, 2009 at 1:41 PM, Matthew Elder <sse...@gmail.com> wrote:
>
> Can you integrate it into the http server code? I would love to see a
> patch. Again, not concerned with rfc's as much as I am a working
> product :)

I think I'll wait a little bit to see how this server stuff shakes
down. I hate creating inapplicable patches. :)

--
gwern

[Clifford Beshers]

On Thu, Jan 22, 2009 at 10:57 AM, Matthew Elder <ma...@mattelder.org> wrote:

> It would be very helpful if the components were split into separate
> darcs repositories the way the ones at happs.org were. 

I agree this is helpful for the end user, but most end users will not use darcs -- they will use the cabal packages.

Do you have any data to support that?  Looking through our config file, I find that we do both.
 

 

> This makes it
> easier to use one component without all the others, or more
> importantly to pull patches into one component without pulling them
> into all the others.

I don't fully see the use case for this. The repository is mainly for developers, and as a developer I find putting all the packages in one repository more convenient.

It's convenient when everything works and when you want all the new features.  It's very inconvenient when just one or two things break for a while and you need to hold them back.

[Gwern Branwen]

sm tells me that one of the issues with the current monolithic repo is
that it discarded all the previous development history (which
certainly seems to be true). This wasn't necessary, of course, thanks
to Darcs's patch stuff. Nothing says one couldn't create a single
consolidated repository containing the history of all the previous
HAppS repositories, I don't think.

Suppose one has the repos:

begin/ data/ dns/ ixset/ server/ state/ util/

Designate an arbitrary one to be the master - begin, say.
cd inside begin, do a mkdir begin, darcs add && record begin, then
darcs mv * begin/ && record --all. At this point, now 'ls begin'
shows nothing except another begin/ with all the actual stuff in it.
(Obviously _darcs remains where it was.)

Now you pull all the patches from, say, server/. This will leave ./
full of happs-server stuff. Do a mkdir happs-server...

It's tedious and a bit tricky to make sure you move all the files into
the right subdirectory, but it's definitely doable and superior to
erasing the history.

--
gwern

[Creighton Hogg]

On Thu, Jan 22, 2009 at 1:02 PM, Clifford Beshers
<clifford...@gmail.com> wrote:
>
>
> On Thu, Jan 22, 2009 at 10:57 AM, Matthew Elder <ma...@mattelder.org> wrote:
>>
>> > It would be very helpful if the components were split into separate
>> > darcs repositories the way the ones at happs.org were.
>> I agree this is helpful for the end user, but most end users will not use
>> darcs -- they will use the cabal packages.
>
> Do you have any data to support that? Looking through our config file, I
> find that we do both.

I think it's more the goal than empiricism. Personally I hate it when
a project requires you to use the current dev version rather than the
released package.

Also, I think there's a distinct advantage to having it all in one
darcs repo while we're currently doing Mad Re-Org and moving code
between various cabal packages.

[Matthew Elder]

It's convenient when everything works and when you want all the new features.  It's very inconvenient when just one or two things break for a while and you need to hold them back.

 

I will concede the point that by not mapping each library to its own repository makes extracting individual tags more bothersome, but at the same time it is not unreasonable to navigate to the desired repository state, and then copy those files out.

 

Aside from that, there is some files that need to be moved from one package to another package for example in the case of HAppS-Extra. If we have separate repositories we lose in a sense the complete history of that move because it will now be fragmented.

 

There is no perfect solution and I am simply trying to choose the most flexible one and also one that will make it easier for developers to contribute.

 

-- Matt

[stepcut]

If I do a pull in the single repo system, how do I know which cabal
packages need to be rebuilt? Currently it is easy to see that only
HAppS-Server has been updated, so nothing else needs to be rebuilt.
But if everything is in a single repo, then I have either just rebuild
everything, or look closely at the patches and figure out
which .cabal packages have changed?

thanks.
- j

[Matthew Elder]

I don't deny the value of having this history, but at the same time, can you realistically think of a use case for rolling back patches that are years old at this point? If the use case is compelling enough I might consider it.

[Matthew Elder]

Agreed.

[Matthew Elder]

Darcs Annotate:

http://darcs.net/manual/node8.html#SECTION008102000000000000000

 

it allows you to see when a directory or list of files was last changed.

[tphyahoo]

I add my vote to "one package to rule them all." Or at most, two:
happs-core plus happs-extras.

cabal install does make haps a bit easier to install against multiple
package dependencies, but despite trying to break things down in a
newbie friendly way on happstutorial, this seems to still be tripping
people up.

I would choose being much more newbie friendly over being slightly
more developer friendly. Projects thrive when they get users, and
users want to get things done, not get bogged down in complication.
Let happs thrive!

On Jan 22, 11:09 am, Creighton Hogg <wch...@gmail.com> wrote:
> On Thu, Jan 22, 2009 at 1:02 PM, Clifford Beshers
>

> <clifford.besh...@gmail.com> wrote:

[Andrea Vezzosi]

Hi,
I tried applying this patch but it looks like you've recorded the
wrong things: modules are just removed instead of moved (you didn't
use darcs move maybe?), HAppS-Extra is empty, and there are some
non-related modifications to HAppS-Plugins.

[Creighton Hogg]

Bah!
I haven't used darcs too often so I had a feeling I'd mess something
up. I'll fix it & I'll commit it to the main repository when I can.

[stepcut]

I already have a library named HAppS-Extra, may you can call yours
something else so I don't have to change all my applications and
purge libghc6-happs-extra-* from all my debian repositories. :p

- j

ps. http://src.seereason.com/ghc610/HAppS-Extra/

On Jan 23, 8:40 am, Creighton Hogg <wch...@gmail.com> wrote:
> Bah!
> I haven't used darcs too often so I had a feeling I'd mess something
> up.  I'll fix it & I'll commit it to the main repository when I can.
>

[Matthew Elder]

ouch, ok, how about HAppS-Contrib ? this is a generic term for "non essential stuff".

[Creighton Hogg]

Sounds good. Sorry about that.

[Gregg Reynolds]

On Wed, Jan 21, 2009 at 6:45 PM, Matthew Elder <ma...@mattelder.org> wrote:
> Taking over the old site is not an option right now, unless Alex Jacobson
> shows up. He is the one with the keys.
>
> On Wed, Jan 21, 2009 at 4:43 PM, Simon Michael <si...@joyful.com> wrote:
>>
>> Glad we got that clear. :) Is there any chance we can keep calling it
>> happs then, and take over or shut down the old site ?

FYI, bottom of page at happs.org:

"Copyright (c) 2007. HAppS LLC. HAppS (tm) is a trademark of HAppS
LLC. All Rights Reserved. "

[stepcut]

Ha! I was only half-joking. But I think I like HAppS-Contrib better
anyway.

thanks!
- j

On Jan 23, 10:34 am, Matthew Elder <m...@mattelder.org> wrote:
> ouch, ok, how about HAppS-Contrib ? this is a generic term for "non
> essential stuff".
>
>
>
> On Fri, Jan 23, 2009 at 8:30 AM, stepcut <jer...@n-heptane.com> wrote:
>
> > I already have a library named HAppS-Extra, may you can call yours
> > something else so I don't have to change all my applications and
> > purge  libghc6-happs-extra-* from all my debian repositories. :p
>
> > - j
>

> > ps.http://src.seereason.com/ghc610/HAppS-Extra/

>
> > On Jan 23, 8:40 am, Creighton Hogg <wch...@gmail.com> wrote:
> > > Bah!
> > > I haven't used darcs too often so I had a feeling I'd mess something
> > > up.  I'll fix it & I'll commit it to the main repository when I can.
>
> > > On Fri, Jan 23, 2009 at 7:23 AM, Andrea Vezzosi <sanzhi...@gmail.com>
> > wrote:
>
> > > > Hi,
> > > > I tried applying this patch but it looks like you've recorded the
> > > > wrong things: modules are just removed instead of moved (you didn't
> > > > use darcs move maybe?), HAppS-Extra is empty, and there are some
> > > > non-related modifications to HAppS-Plugins.
>
> >  > > On Thu, Jan 22, 2009 at 5:19 PM, Creighton Hogg <wch...@gmail.com>
> > wrote:
> > > >> Hello,
>
> > > >> The attached should be a patch to move the facebook module & the two
> > > >> modules that depend on it into a new directory called HAppS-Extras.
> > > >> Unless I messed up the darcs recording, this should work.  The cabal
> > > >> file for HAppS-Extras isn't optimal yet & could probably be pruned.
>

> --
> Matthew Elder
> Mr. Handsome

[Andrey Chudnov]

Hi Matthew (and all the fellow HAppS enthusiasts),
You certainly do write in quite a persuasive way. But, I'd like to
have some comments from Alex regarding the orphaning of HAppS. I hear
about it for the first time. And, what would be the license and the
copyright for Happstack? The "Copyright HAppS, LLC." requirement kinda
bugged me a lot, especially not knowing what this "HAppS, LLC." was.

I followed HAppS loosely for about 2 years now and even considered
contributing, but the licensing-related questions plus the lack of
developer documentation for both the current and the future code (aka
roadmaps) were on my way.

I think HAppS had some great ideas:
* Haskell can help produce more reliable and secure web apps, which is
definitely a virtue nowadays :)
* Promised an easy-to-use distributed backend which would give anyone
a possibility to compete with guys like Google or Amazon.

But, I don't see it on the way to implement these ideas. One of the
biggest disappointment that the backend (HAppS-State) wasn't designed
to be reliable, e.g. Lemmih once mentioned that if the state on one of
the shards is lost, for example, due to a power failure than it is
just gone, because all info is in volatile memory. And I haven't seen
any evidence of that being fixed. This is just crazy, no one serious
about their data would use a system with such "guarantees".

As for suggestions...

Here's the list of things that I'd like to see in Happstack, because
they are important and because it _is_ possible to have them:
* easy to use, reliable distributed back-end with support for
sharding, replication and transactions (even cross-shard ones).
* modular structure that would enable to use other back-ends, like an
RDBMS. It would be nice if would be an easy path to migrate from
RDBMS to HAppS-State. One should be able to use different front ends
too (equal support for HSP and Data.HTML and whatever other solutions
for describing the resulting web page are there).
* build with security by default: built-in protection against
injection attacks, CSRF etc. Authentication and SSL are also a must
(if you want Fortune 500 to hire you at the end :)).
* nice embedded languages for defining routes and action handlers,
form building and processing and working with the back-end (ideally,
abstracted away the specific back-end in use). Would be nice to have
an ajax library as well (or some nice interoperability with an
existing one).
* some nice libraries for doing common tasks (scaffolding, for
example).
* an easy way to remotely administer (launch, stop, configure) the
instances. Some kind of protocol, I guess.
* restrict the usage of GHC extensions. Personally, I'd try to keep it
as close to Haskell'98 as possible.

Regarding the development process:
* Liberalization is good, but there should be a team of super-
developers that would define the architecture and the roadmap clearly,
so that the project doesn't drift.
* Documentation, bug tracking and a precise list of project
participants (including who is doing what) is a must.
* Justifications for high-level architectural decisions, the usage of
non-haskell libraries (like Spread) and the restrictions on the usage
of GHC extensions should be clearly outlined and available to all
current and potential contributors.

As for me, I might be able to join as a developer. I'm familiar with
Haskell and not scared of monads, although haven't written anything in
it for a year. The best thing I can do is, probably, the security part
I outlined above. Although, I'm also very much interested in the HAppS-
State (or whatever it would be called in the fork).

Cheers,
Andrey

On Jan 21, 6:45 pm, Matthew Elder <m...@mattelder.org> wrote:
> Attention HAppS Enthusiasts!
>
> I am reaching out to find other like-minded individuals who want to develop,
> test, and use HAppS but feel a bit weary that the project is losing
> momentum. Alex Jacobsen has done a lot of work to build the coherent
> platform that exists today -- but it still is wanting of some love.
>
> In particular:
>
> 1. Only a few people can commit to the HAppS codebase
> 2. Documentation is lacking
> 3. Test coverage is lacking
> 4. The code needs a lot of cleanup!
>
> So what are we to do now? We can go on our merry way and allow it to
> silently slip away. The project will eventually be superceded by other
> Haskell frameworks like Turbinado which are not nearly as innovative -- and
> interest will wane. The heyday of databases will continue for another
> decade, and we can all cuddle up to our loved ones and have peace of mind.
> Then we will always ask ourself, what if HAppS and more importantly MACID
> would have changed the landscape of web applications as we know it?
>
> What if instead we pick up the torch and keep the flame alive? What if we
> pick up our keyboards and hack like we've never hacked before, collaborate
> like we've never collaborated before? What if the Java Despots and the
> Python Conglomorates fall, and fortune 500 companies pound down our doors
> with job opportunities? Well, that could happen, maybe...
>
> So what are we waiting for? Let's band together and start afresh with the
> HAppS vision and mold it into something truly formidable! What I propose:
>
> 1. Consolidate the code that makes happs up into one repository and adopt a
> much more liberal development strategy.
> 2. Identify our own strengths and share the load in order to make HAppS the
> best it can be!
>
> I am kicking off this project in the hopes that all who enjoy haskell and
> want to bridge the gap between the hohum world of web programming and
> lambdas to make the most glorious app server ever!
>
> I am forking the HAppS project under the banner of Happstack in the hope
> that all who are able and willing will join me! Please join us on #happs
> when you have the time, or simply respond to this thread on the mailing
> list. We will be giving out commit rights, collaborating, and getting to
> know each other in general.
>
> For more information, please see the newly minted
> website<http://happstack.com/>and
> blog <http://blog.happstack.com/>.
>
> Your partner in the new revolution,
> Matthew Elder

[Matthew Elder]

Hi Matthew (and all the fellow HAppS enthusiasts),
You certainly do write in quite a persuasive way. But, I'd like to
have some comments from Alex regarding the orphaning of HAppS. I hear
about it for the first time. And, what would be the license and the
copyright for Happstack? The "Copyright HAppS, LLC." requirement kinda
bugged me a lot, especially not knowing what this "HAppS, LLC." was.

Please read the FAQ: http://happstack.com/faq.html

Regarding  Happstack license and copyright, it will be a very liberal bsd license (the most liberal that the current license will compatibly allow -- I am not a license expert by any stretch of the imagination). Copyright is obviously shared between HAppS LLC, and the various contributors -- and it will continue to be this way. From my point of view it doesn't matter too much as the license already permits you to do pretty much anything you want with it.
 

I followed HAppS loosely for about 2 years now and even considered
contributing, but the licensing-related questions plus the lack of
developer documentation for both the current and the future code (aka
roadmaps) were on my way.

One of the goals of Happstack is improved documentation. A roadmap will be outlined in the next week or two.
 

I think HAppS had some great ideas:
* Haskell can help produce more reliable and secure web apps, which is
definitely a virtue nowadays :)
* Promised an easy-to-use distributed backend which would give anyone
a possibility to compete with guys like Google or Amazon.

But, I don't see it on the way to implement these ideas. One of the
biggest disappointment that the backend (HAppS-State) wasn't designed
to be reliable, e.g. Lemmih once mentioned that if the state on one of
the shards is lost, for example, due to  a power failure than it is
just gone, because all info is in volatile memory. And I haven't seen
any evidence of that being fixed. This is just crazy, no one serious
about their data would use a system with such "guarantees".

The way the system functions currently, is that data is also written to disk. You have the same durability as an SQL database. Obviously the system needs to have some more testing (automated and field) before it can be considered "production ready" on par with something like mysql.

As for suggestions...

Here's the list of things that I'd like to see in Happstack, because
they are important and because it _is_ possible to have them:
* easy to use, reliable distributed back-end with support for
sharding, replication and transactions (even cross-shard ones).

This is half-implemented, If you are interested in finishing this, pick Lemmih's brain.
 

* modular structure that would enable to use other back-ends, like an
RDBMS. It would be nice if would be an easy path to migrate from
RDBMS to HAppS-State. One should be able to use different front ends
too (equal support for HSP and Data.HTML and whatever other solutions
for describing the resulting web page are there).

You are not forced to use MACID. You can easily tie in something like haskelldb or takusen for this. A high level wrapper akin to an ORM is going to be out of scope for what Happstack is trying to accomplish -- there is already a project called Turbinado which does just this.

* build with security by default: built-in protection against
injection attacks, CSRF etc. Authentication and SSL are also a must
(if you want Fortune 500 to hire you at the end :)).

Injection attacks don't exist with MACID, but yes I do agree that security is very important. SSL is out of scope for Happstack as well because it is meant to be an appserver, not a full blow webserver. SSL is easily achieved with a proxy back end via something like apache, lighttpd, or nginx.

* nice embedded languages for defining routes and action handlers,
form building and processing and working with the back-end (ideally,
abstracted away the specific back-end in use). Would be nice to have
an ajax library as well (or some nice interoperability with an
existing one).

I don't know about embedded languages, but I definitely think that route handling could be nicer. I think someone is working on a type-safe way to do consistent routing both at the http level and when generating pages.

* some nice libraries for doing common tasks (scaffolding, for
example).

A standardized project skeleton would be fantastic but we need to be careful to not try to generalize this too much and fall into the same traps that Rails did.

* an easy way to remotely administer (launch, stop, configure) the
instances. Some kind of protocol, I guess.

This happens amongst shards/replication partners right now with Spread, but I agree that more visibility into it would be quite useful. Do you want to build this tool? :) Again talk to Lemmih and pick his brain about the Spread stuff.
 

* restrict the usage of GHC extensions. Personally, I'd try to keep it
as close to Haskell'98 as possible.

I have mixed feelings about this. Yes I want to avoid and even reduce the current trend of using esoteric GHC extensions -- but at the same time some extensions like template haskell and SYB really make sense for certain parts of the current system.

Regarding the development process:
* Liberalization is good, but there should be a team of super-
developers that would define the architecture and the roadmap clearly,
so that the project doesn't drift.

By liberalization I mean free flowing of ideas and patches. As far as organizational structure I want to emulate what Linus has. Benevolent dictator with lieutenants for different areas of responsibility -- a chain of command; I want to absolutely avoid petty arguments, flame wars, ego trips and all of that as much as possible. If I get hit by a bus or drop off the face of the earth it is understood that a lieutenant will step up and take complete control of the project (the contingencies will be in place beforehand).

* Documentation, bug tracking and a precise list of project
participants (including who is doing what) is a must.

Bug tracking - Done.
Precise List - On the todo list.

* Justifications for high-level architectural decisions, the usage of
non-haskell libraries (like Spread) and the restrictions on the usage
of GHC extensions should be clearly outlined and available to all
current and potential contributors.

Who are we trying to justify ourselves to? I think its great to have this kind of documentation and I would even encourage it but we shouldn't feel the need to defend every decision we make to everyone. A better defense against naysayers is to simply prove them wrong by getting stuff done in the real world with this project.
 

As for me, I might be able to join as a developer. I'm familiar with
Haskell and not scared of monads, although haven't written anything in
it for a year. The best thing I can do is, probably, the security part
I outlined above. Although, I'm also very much interested in the HAppS-
State (or whatever it would be called in the fork).

I would love for you to get on board. I hope I haven't scared you away with the previous replies :)
 

[Andrey Chudnov]

> Please read the FAQ:http://happstack.com/faq.html

I did :) The argument about HAppS being orphaned points to a fresh
posting by Lemmih. I think, it would be nice to have Alex post his
endorsement of what's going on.

> The way the system functions currently, is that data is also written to
> disk. You have the same durability as an SQL database. Obviously the system
> needs to have some more testing (automated and field) before it can be
> considered "production ready" on par with something like mysql.

Just to make sure I get things right. Last time I looked at how the
data saved on the disk, it was done by checkpointing, which, due to
the fact it takes considerable time, is recommended to be done at the
server start or shutdown (correct me if that has been changed). Now,
if something happens to the server in between the checkpoints -- the
data is lost. The way it is done in most systems (I think) is that the
change is saved to a log on disk _before_ it is committed, i.e. the
change is visible to other processes/users. Let me know if that is the
current behavior. Otherwise, HAppS-State may be in a trouble.

> Injection attacks don't exist with MACID,

If you're talking about SQL injection - I totally agree with you.
Cross-site scripting is an injection attack as well and MACID won't
help you with that. That way it could be solved is by forcing any user-
generated content to be html-escaped before output. This could be
nicely forced by a type system. Cross-site request forgery attacks are
also important and have a couple of ways of protecting against, but
MACID is not in that list. :)

> but yes I do agree that security
> is very important. SSL is out of scope for Happstack as well because it is
> meant to be an appserver, not a full blow webserver. SSL is easily achieved
> with a proxy back end via something like apache, lighttpd, or nginx.

Well, I would say, why use proxy servers? It's an unnecessary
complication of configuration. One of the HAppS intended features was
ease-of-deployment (like getting rid of an RDBMS and having a single
executable to run with integrated web, persistence, SMTP, DNS etc.)
and I'd two hands up to see that.

> I don't know about embedded languages, but I definitely think that route
> handling could be nicer. I think someone is working on a type-safe way to do
> consistent routing both at the http level and when generating pages.

Here are some examples of embedded languages:
http://www.haskell.org/haskellwiki/Research_papers/Domain_specific_languages

> A standardized project skeleton would be fantastic but we need to be careful
> to not try to generalize this too much and fall into the same traps that
> Rails did.

I'm not talking about a skeleton. I'm talking about generating an web
interface with CRUD operations for the data types in MACID. That's
just an example of stuff that definitely saves some time. I think that
Rails' trap was the Ruby language and the lack of modularity. HAppS
seemed to avoid those so far, so I'm happy with that :)

> This happens amongst shards/replication partners right now with Spread, but
> I agree that more visibility into it would be quite useful. Do you want to
> build this tool? :)

No, at least not now. And I've already outlined my area of interest
and expertise (that was security).

> I have mixed feelings about this. Yes I want to avoid and even reduce the
> current trend of using esoteric GHC extensions -- but at the same time some
> extensions like template haskell and SYB really make sense for certain parts
> of the current system.

Well, if they _really_ make sense - then it's okay. But it might be
that it was the over-obsession with the bleeding-edge GHC features
which caused tons of compilation errors people reported here.

> Precise List - On the todo list.

Where is the todo list?

> Who are we trying to justify ourselves to?

Well, nobody is - that's the point.

> I think its great to have this
> kind of documentation and I would even encourage it but we shouldn't feel
> the need to defend every decision we make to everyone. A better defense

> against naysayers is to simply prove them wrong by *getting stuff done* in

> the real world with this project.

I think writing some kind of high-level documentation outlining the
major decisions and the architecture is a good way of catching errors
early, until they become a problem too big to handle. And they also
would give a nice way for the potential contributors (like me) to
quickly evaluate whether the project is worth of contributing to.

> I would love for you to get on board. I hope I haven't scared you away with
> the previous replies :)

No, you haven't. But, I'll need to see the roadmap first. :)

BTW, is that you? http://www.cs.virginia.edu/~mce7e/

[Matthew Elder]

On Fri, Jan 23, 2009 at 7:36 PM, Andrey Chudnov <achu...@gmail.com> wrote:

> Please read the FAQ:http://happstack.com/faq.html

I did :) The argument about HAppS being orphaned points to a fresh
posting by Lemmih. I think, it would be nice to have Alex post his
endorsement of what's going on.

I think you missed this (it was updated today):

Why hasn't Alex Jacobson made a statement regarding the project being orphaned?

I don't know. If you want to ask him yourself contact me in private and I will give you his phone number.

> The way the system functions currently, is that data is also written to

> disk. You have the same durability as an SQL database. Obviously the system
> needs to have some more testing (automated and field) before it can be
> considered "production ready" on par with something like mysql.

Just to make sure I get things right. Last time I looked at how the
data saved on the disk, it was done by checkpointing, which, due to
the fact it takes considerable time, is recommended to be done at the
server start or shutdown (correct me if that has been changed). Now,
if something happens to the server in between the checkpoints -- the
data is lost. The way it is done in most systems (I think) is that the
change is saved to a log on disk _before_ it is committed, i.e. the
change is visible to other processes/users. Let me know if that is the
current behavior. Otherwise, HAppS-State may be in a trouble.

Checkpointing consolidates state events. You always have durability against unexpected shutdowns because the events, like an sql log, is written to disk before the transaction can complete. HAppS state behaves exactly like a database such as mysql when it comes to ACID guarantees.
 

> Injection attacks don't exist with MACID,

If you're talking about SQL injection - I totally agree with you.
Cross-site scripting is an injection attack as well and MACID won't
help you with that. That way it could be solved is by forcing any user-
generated content to be html-escaped before output. This could be
nicely forced by a type system. Cross-site request forgery attacks are
also important and have a couple of ways of protecting against, but
MACID is not in that list. :)

IT would be difficult to enforce this behavior without sacrificing flexibility. People will shoot themselves in the foot, no matter how hard you try to prevent it :)

 

> Precise List - On the todo list.

Where is the todo list?

On my desk. The project to-do list is http://code.google.com/p/happstack/issues/list

[Lally Singh]

Hi folks, a few ideas:

- I'm new to Haskell, and HAppS, but I've been programming for a long
time. I think there are a few of us in the same situation. Could we
take active bugs and then beg & claw our way into getting enough
information about HAppS(tack) to fix them?

- As for documenting design decisions, etc. The best format would be
articles on the various topics. Edit them to answer questions as they
come, and the articles will serve as great documentation, and serve to
make HAppS that more interesting & approachable by others. It also
gives happstack.org content and makes it a stronger hub for the
community

- Wonderful job on happstack.org, btw. It's nice to see the reference
links there without having to scour google and filter the good vs the
bad vs the obsolete.

--
H. Lally Singh
Ph.D. Candidate, Computer Science
Virginia Tech

[Matthew Elder]

- I'm new to Haskell, and HAppS, but I've been programming for a long
time.  I think there are a few of us in the same situation.  Could we
take active bugs and then beg & claw our way into getting enough
information about HAppS(tack) to fix them?

That's sort of what we are doing, but we could definitely use some help!
 

- As for documenting design decisions, etc.  The best format would be
articles on the various topics.  Edit them to answer questions as they
come, and the articles will serve as great documentation, and serve to
make HAppS that more interesting & approachable by others.  It also
gives happstack.org content and makes it a stronger hub for the
community

Yeah, I think casual ad-hoc documentation can go on the wiki. Stuff that has solidified will go on happstack.com

- Wonderful job on happstack.org, btw.  It's nice to see the reference
links there without having to scour google and filter the good vs the
bad vs the obsolete.

You mean happstack.com right? Thanks :)