== HList or HSXML as input/ouput types for HAppS Handlers ==

A major portion of HAppS work is defining the data types consumed and returned by handler functions.  Using HList ad-hoc
extensible records is appealing because the use of the types defines what they must be.  But using HList instead of
traditional Haskell records requires overcoming a couple of barriers:

 * generic generation of XML/JSON from HLists

Currently, the user must manually define ToElement instances for all output types.  It is not clear how to do this with
HLists and it would be really nice if it was simply unnecessary because HLists had a standard encoding as XML and/or
JSON.  Oleg addressed this issue to an extent in his HSXML work, but it is not entirely clear whether the HSXML data
structures are also easy to use as extensible records.

 * generic consumption/validation of XML/URLEncoded data

Currently, the user must manually define FromMessage instances for all input types.  Generic parsing for the required
extensible record would be really great.  Even better would be a way to define constraints on incoming messages so that
violation of the constraints is interpreted as a parser failure e.g. that a particular value is within some bounds.  It
is actually much more useful to be able to consume URLEncoded data than XML.  But, both would be nice.  From AlexJ's
review of Oleg's HSXML stuff, it doesn't look like Oleg is supporting parsing.

 * indexed sets

Currently, HAppS.DMBS (experimentally) provides users with a way to create indexed sets that allow efficient
querying/relational operations on (Data.Set a).  For example, a user might maintain a set of Sales and want to look up
all transactions from a particular CustomerID or within a particular Date range.  Effectively we have something that
looks like an in-memory type-safe relational database for Haskell objects.  If we convert to using HList extensible
records, we need a way to manage collections of these things.  It would be really great for someone to rewrite the DBMS
code so a user could statically define a collection of extensible records by the labels on which the collection should
be indexed.

 * Flexible/Extensible Record Binary Serialization

Currently, state in HAppS applications is defined using Haskell records and is serialized using a wrapper around
Read/Show.  When the user decided to modify the shape of the state type and restart the server, state fails to serialize
unless the user has written annoying code to read in the old state type and convert it to the new state type.  A state
type defined in terms of HList extensible records could define a default value for any field that does not appear in the
deserialized state and ignore any field from the serialized type that is no longer in the live state.  It would be even
better if the serialization for these HLists was some concise binary format so as to speed checkpointing and recovery
for large states.

== Add dynamic reloading support via hs-plugins or ghc-api  ==

Currently, every change to a HAppS applications requires compiling and restarting the server to test the changes.
Making HAppS applications dynamically reload the code with every change to the source (as if running Perl/CGI) would
substantially speed the development/debug process.

== Fix rspErr so that the user can catch exceptions and decide how to handle them ==

AlexJ now has rspErr in HAppS.Protocols.SimpleHTTP2.  Conceptually this should allow any HTTP handler to throw any
exception and then have the user add a response filter to do something intelligent with it.  In practice, the catch
implementation in that code does not appear to be working.  Fix it!

== Improvements to the Saver API ==

HAppS Saver abstracts out the underlying filesystem so we can do clever things like run without modification on Amazon
S3/EC2.  So any interaction with the filesystem needs a specific API....

 * General error logging added to the saver API and default saver

A general purpose facility for error logging would also be really useful.  I think this requires modifying the saver API
so this is some in depth munging inside HAppS.

 * Add berkleyDB style API for handlers.

Sometimes you want to deal with data that really doesn't fit in memory e.g. images or video.  It would be good to add a
standard interface to the Saver to store BLOBs.  We don't really want HAppS applications to depend on particular file
system structure.

== Fix the ugliness of SURI vs Network.URI ==

Currently HAppS uses HAppS.Protocols.SURI instead of Network.URI in a lot of contexts because Network.URI doesn't
implement Read/Show.  The result is ugliness, type confusion, and impedance matching around URI stuff that should really
be unnecessary.  Fix it!

== FlapJax -- Functional Reactive Haskell ==

Write flapjax style client code in Haskell with the compiler checking the validity of the code.  The server then
dynamically generates the correct javascript.  The value here is that the compiler checks the validity of the code and
also checks that the server and client types match.

== Good general purpose Comet/server-push support ==

Comet is the name given to various strategies that allow the server to push events to the client.  The typical
implementation involves the client making an HTTP request to the server and the server waiting to respond to that
request until it has data.  AlexJ has some sample code that does this, but it would be nice to have a general purpose
API for this sort of thing.  The correct API and implementation for this probably requires some discussion.

See http://www.irishdev.com/NewsArticle.aspx?id=2166 for a useful explanation of Comet.

== Improve XSLT Handling ==

 * The code that detects whether to do XSLT on the server or on the client is not very smart. 
   Fix it for proper client-side xslt capability detection.

 * Modify the XML generating code to provide an absolute URL for the stylesheet so the server side XSLT is guaranteed to
   use the same stylesheet as the client and there is no risk of confusion.

 * Should server side XSLT be done by calling out to xsltproc as it is now, or by using a Haskell XSLT implementation?

== Performance Improvement for SMP/multi-core ==

 * Modify STM and HAppS to make MACID take advantage of multiple CPUs -- allow simultaneous execution of multiple
   transactions as long as they don't conflict!

 * Investigate shifting the API to arrows rather than monad to distribute functions on multiple CPUs for a better
   approximation of SEDA and more scalability?

== Add caching to the HTTP Client library ==

HTTP caching would allow apps to retrieve and later use HTTP content from other servers.  Ideally the full parse and
interpretation of the requested content is cached and not just the raw bytes.

== Add a credit card payment example that uses WithBlockingIO ==

Self explanatory.  I can provide some credit card payment APIs if useful.

== Improve Cookie Security ==

In http://groups.google.com/group/HAppS/msg/2934bd834f7a19f2 Tim Newsham points out that session keys are small and
produced by a pseudo-random number generator. This is not as secure as it could be and means that sessions could be
hijacked by a brute force attack.
