GSoC project ideas for web technology

[Jeremy Shaw]

Hello,

If you are looking for some ideas for a GSoC project, I have written down
some web technology related projects I would like to see.

So far I mostly have ideas for improvements to HSX (a templating solution)
and acid-state (a pure, haskell persistent datastore). Both these
technologies can be used with any Haskell web framework (though they are
embraced most fully by Happstack).

http://code.google.com/p/happstack/wiki/GoogleSummerOfCode

I am an officially registered Haskell GSoC mentor. I am happy to help
expand any of these ideas into a genuine GSoC proposal and to act as a
mentor on the project. If you have other ideas you wish to pitch, I am
happy to hear those as well.

- jeremy

[Aidan Delaney]

Jeremy,
I'd really like to see a GSOC project that implements a number of
"standard" applications on top of Happstack. For example, a small
CMS, a simple shopping basket and a twitter/identi.ca clone. These
are less technical than diving into Happstack itself but I think would
demonstrate that the Happstack approach (extending to Yesod etc...)
can be used to develop modern web applications. Once people can see
that you can do "standard" things and then know the advantages that
the type-safety allows then ... world domination.

[Jeremy Shaw]

Post by Aidan Delaney
Jeremy,
I'd really like to see a GSOC project that implements a number of
"standard" applications on top of Happstack. For example, a small
CMS, a simple shopping basket and a twitter/identi.ca clone.

A CMS would be a great project. A shopping basket would be an excellent
addition to such a CMS.

Not sure if a twitter/identi.ca clone is a worthy endeavor. Part of what
makes twitter interesting is is ability to support a gigantic number of
users. With a clone, it is difficult to show that you could handle the same
workload. A twitter clone that support dozens of users is not very
impressive :) Investing a lot of time in a site that no one will actually
use seems like time that could be better spent building something people
actually want.

These

Post by Aidan Delaney
are less technical than diving into Happstack itself but I think would
demonstrate that the Happstack approach (extending to Yesod etc...)
can be used to develop modern web applications. Once people can see
that you can do "standard" things and then know the advantages that
the type-safety allows then ... world domination.

I don't think proof that it can be done is the issue. The bigger issue is
providing the ecosystem that makes it worthwhile. A key piece is the
ability to quickly assemble a site using off the shelf components that
actually work together. Shopping cart, mailing lists, subscription
management, user accounts, etc. That is definitely in the roadmap for
Happstack. Though, there are still some core technology issues I would to
address first. That includes:

- updating the happstack-server HTTP backend to something more modern and
faster with better resource finalization. The current backend is actually
pretty good. But, the fact that it could be better eats at my soul.

- acid-state needs some acceptable answers to replication and to how to
scale beyond the bounds of RAM. While most people will never *need* those
features, it is comforting to know that a solution does exist if you should
ever reach that point.

- HSX is a very good concept for a templating system. The implementation
could use some improvements and updates however. For example, it should be
modernized to work with Text/Bytestring instead of String. And it needs to
integrate better with OverloadedStrings. Also, it has support for writing
templates that look and feel a lot like normal external HTML template
files, but it could create an even better illusion. And, finally, there is
some important work that could be done to improve the error messages.

- happstack-plugins needs more love to make it work more reliably. Really
it is the underlying plugins library that needs work. It needs to be
updated to use the GHC API. It needs better support for building source
that is in a different location than current working directory, etc. Also,
the inotify code needs to be refactored so that we can provide a portable
solution that works across linux, OS X, freebsd, Win32.

- web-routes needs to be finished. web-routes was actually conceived as a
system for supporting pluggable components for web applications. The
initial problem I started solving was how to ensure that each component had
unique URLs. Additionally, I wanted to be sure that if a component changed
the URLs it exports that applications using the library got some sort of
compile time error. Once you have those requirements, type-safe URLs
naturally fall out as the solution. There are still some additional
problems that need to be solved though regarding plugin initialization and
resource finalization.


Once those key problems are addressed, I think that providing a good
library of components will be the #1 task. Of course, we can start
developing some of those components now, such as happstack-authenticate.

- jeremy