I'd also be interested in a system that handled overlapped asynchronous requests
in a fashion not dissimilar to Twisted [5].
I see you just saw the HAppS announcement. You'll appreciate that
HAppS was actually inspired by Twisted (and Prevayler).
over time. It seems to me that the sequencing of asynchronous operations is
very much like threading computations in a monad, and that the higher-order
functions on monads could also be used for composition of asynchronous
operations.
Yup you got it. The two big issues are ACID semantics (for any
server) and handling of side effects. HAppS does write ahead logging
and checkpointing to give you the ACID stuff and provides
infrastructure so you can guarantee at-least-once execution of side
effects.
As for "web dispatching", the application model in HAppS is to help
you separate state, application logic, wire formats, protocols, and
presentation layer:
* State
State is just a haskell data type you define. ACID Consistency
enforced by Haskell's type system. ACID Durability is handled by
MACID write-ahead logging and checkpointing.
* Application
Incoming events are gathered in individual haskell threads and
then pushed onto a single application queue for processing. The
queue model gives you ACID Atomicity and Isolation and lets your
app be simply a set of functions with types like:
SomeInputType -> MACID SomeOutputType
The MACID monad lets you update your state and *schedule*
side-effects. To be clear, MACID is not in the IO monad so you
cannot execute sideeffects, you can only schedule them. The
framework takes care of making sure they are executed
at-least-once (if they can be completed by a deadline you
specify).
* Wire Formats
Since your app consists of a set of functions with various haskell
input and output types, somewhere you need a place to convert
between those internal haskell types and external protocol event
types; e.g. from URLEncoded HTTP requests to SomeInputType and
from SomeOutputType to XML encoded HTTP responses.
* Protocols
HAppS currently provides support for HTTP Requests/Responses and
SMTP Envelopes. To be clear HApps provides ACID Atomicity at the
protocol event level. So if you write a protocol with SMTP
envelopes being the arriving event type then your app will have
atomicity in processing incoming SMTP envelopes. If you write a
protocol with SMTP commands being the arriving event type, then
your app will have atomicity at the level of individual smtp
commands.
* Presentation
If your application outputs XML as its wire format, HAppS provides
a lot of support for using XSLT to transform it for presentation
purposes. For example, you can send XML mail and HAppS will take
care of applying the relevant XSLT stylesheet before it is
delivered. If you output XML HTTP responses, HAppS takes care of
applying the XSLT stylesheet server side for user-agents that
don't support doing so on the client. The value here is that you
can have designer types who know XSLT modify presentation stuff
without touching your application code.
-Alex-
______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Wed, 12 Apr 2006, Graham Klyne wrote:
I'm interested, but I don't have the time to look right now (or in the next
couple of months, as far as I can see).
What would really interest me is a system that can provide the functionality of
the Python packages I currently use (TurboGears [1], of which the web
server/controller component is CherryPy [2]). There's also some interesting
recent CherryPy-related discussion about web dispatching that I think could
translate very well to Haskell [3][4].
...
I'd also be interested in a system that handled overlapped asynchronous requests
in a fashion not dissimilar to Twisted [5]. I've very recently been playing
with Twisted as a way to deal with large numbers of overlapping lightweight
requests without having large numbers of active threads. Twisted requires one
to string together asynchronous callbacks to assemble a process that completes
over time. It seems to me that the sequencing of asynchronous operations is
very much like threading computations in a monad, and that the higher-order
functions on monads could also be used for composition of asynchronous
operations. I just implemented a "sequence" function for Twisted operations
whose implementation started to feel very like "foldr".
This can't be new, and I'm wondering if there is any interesting work out there
on using monads for multiple asynchronous I/O operations. (And, much as I'd
love to use Haskell for this, is there work that would translate cleanly to
Python?)
#g
--
[1] http://www.turbogears.com/
[2] http://www.cherrypy.org/
[3] http://pythonpaste.org/do-it-yourself-framework.html
(cf. descriptions of object publishing)
[4] The above link was posted in this discussion thread:
http://groups.google.com/group/cherrypy-users/browse_frm/thread/47035d8d78adad69/bf02b489e45ce6c5?tvc=1&hl=en#bf02b489e45ce6c5
[5] http://twistedmatrix.com/
http://twistedmatrix.com/projects/core/
Daniel McAllansmith wrote:
Following is a message I sent yesterday, sans attachment. Looks like the code
was too bloated to get through under the list size limit.
As I say in the original message , I'm keen for any feedback. So let me know
if anyone wants the actual code (20 KB, compressed) to have a look through.
Cheerio
Daniel
On Sunday 09 April 2006 06:24, Tim Newsham wrote:
I found a copy of Simon Marlow's HWS on haskell.org's cvs
server. I know there's a newer plugin version, but I cant find a working
link to the actual code.
There's this link: http://www.mdstud.chalmers.se/~md9ms/hws-wp/
From memory I think there may have been a more recent version at
scannedinavian.org (possibly only accessible with darcs?), but still a couple
of years with no apparent activity.
Besides HWS, what other web servers exist? Does anyone actually use a
haskell based web server in practice? Which web server is considered the
most mature? stable? fastest?
I'm trying to decided if I should sink some time into HWS or if I should
use another server.
Several months ago I had a bit of play-time available which I spent on writing
a HTTP server in Haskell.
The goal was a HTTP 1.1 compliant server that could be embedded in a Haskell
app, be reconfigured on the fly and have different request handlers
added/removed.
I did have a quick look at HWS before I started but I seem to recall it was
pretty basic (in terms of the amount of the HTTP spec. implemented).
In any event, I started from scratch. It's certainly not finished, and it's
the very first thing I wrote with Haskell so it's a bit of a dogs breakfast,
but it might be of interest.
There's lots that needs doing but it should just be a case of writing a
request handler to get it doing _something_ useful.
It's always been my intention to get back to it, clean it up a bit/lot and
release it under a more liberal licence (currently 'all rights reserved'),
but have had little time available.
Eventually I hope to actually use it in anger.
If anyone is interested in using it, contributing to it, or picking over it
for use in an existing project, I'll try and find somewhere stable to host it
and change the licence.
Feel free to ask questions on what it does/doesn't do. You'll probably need
to, given the documentation ;-)
Regardless of it's utility, any criticism or advice on the code would be
appreciated.
Daniel
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Graham Klyne
For email:
http://www.ninebynine.org/#Contact
_______________________________________________
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
