[web-devel] Re: ANN: Salvia-1.0.0

[Sebastiaan Visser]

On Mar 21, 2010, at 5:41 PM, Gour wrote:
> On Sun, 21 Mar 2010 17:07:01 +0100
>> 
>> "Sebastiaan" == <sfvisser at cs.uu.nl> wrote:
>> Straight from Zurihac: I'm very pleased to announce the
>> 1.0.0 release of the Salvia web server.
>> 
> 
> Congrats for the "new kid on the haskell's web block". :-)

Thanks! :-)

>> Salvia is a feature rich web server and web application
>> framework that can be used to write dynamic websites in
>> Haskell. From the lower level protocol code up to the high
>> level application code, everything is written as a Salvia
>> handler. This approach makes the framework extremely
>> modular and extensible.
>>> 
>> 
> 
> Am I right, that it uses its own protocol, i.e. no WAI?

To answer your question: yes, Salvia uses its own protocol. Athough the term `protocol' might mean different things when looked at from different perspectives.

How do I put this delicately? I do not think WAI is the way to go.

On the Hackage page of WAI I read: "Provides a common protocol for communication between web aplications and web servers." This means that WAI is a proposed standardized interface intended to sit between server and a web application. There several reasons why I don't like the idea of a standardized interface between the application server and the web application.

First of all, no one will ever agree on this type of interface. Not on the level of abstraction, not on the actual naming of the datatypes, not on the amount of documentation, not on the placement of the parenthesis. I, for example, don't like WAI at all: I do not want be forced to use enumerators for the output, ByteStrings for the input, only 10 predefined response codes, etc. 

Secondly, this type of interface will degrade projects like Happstack and Salvia to be mere `back-ends', which they are not. They are both server implementations _and_ interfaces to the programmer. Salvia for example is designed to be a combinator library (not a fixed API) in which some low-level protocol aspects, like keep-alive, http-range support, REST, serving HEAD requests are implemented in the same paradigm as the higher level web controllers. I truly like this idea and this will be totally invalidated by something like WAI of Hack.

What I do like to see though, is something like the Ruby Rack interface, which calls itself a "a Ruby Webserver Interface". This is an interface between the actual OS/network and the application server, not an interface between an application server and the web application. Call it WSI not WAI, this subtle difference actually means a lot.

This WSI would just give me file handle/socket and possible a pre-parsed HTTP message, but that is all. A Rack-like interface would allow me to run my Salvia web applications on any backend, like CGI, or in mod_haskell, in the blazingly fast iteratee based Hyena or behind an Apache proxy. But still, the web application is written against Salvia (or the framework you like most) and can piggy bag on all the neat features it supplies.

Salvia itself has such a WSI, although I'm pretty sure this one is to abstract and high level to be a true candidate for any form of standardization.

>>   * salvia-demo: Demo servers showing how to use Salvia.
> 
> Is there some docs available besides the above package?

No unfortunately, there is currently only the examples and the haddock documentation. We are working on a tutorial, but that will have to wait for a while. Sorry for that.

>> Most of the basic ideas of the previous Salvia release are
>> still in these package, but all the code has been cleaned
>> up considerably. There is now a very strong separation
>> between interface and implementation making it more easy to
>> plug-in new back-ends for your web application.
>> 
> 
> Any info how much resources it requires, i.e. is it in the category of
> Happs or one can deploy it on shared hosting?

It can run on its own server (like Happs) or as CGI. Whether you can easily deploy it probably depends on your hosting party, not on Salvia.

> Does it play with other servers as proxy?

It can run as CGI or behind existing apache proxies without any problem. The codebase has some experimental support for running Salvia itself as a proxy server, but this code is not released yet because it needs some additional coding/polish/testing.

> Any support for database back-end?

No, this is a web server package not a database. Off course you can use it to build database backed web applications, using any datastore you like. The Salvia project will never have built-in support for any form of data storage, I prefer to keep these aspects totally separated.

>> Thanks to the people that helped me with coding,
>> suggestions and bug-reports. Any comments/suggestions are
>> welcome!
>> 
> 
> Excuse me for maybe dumb questions, but I'd like to hear more before
> venturing into installing several apps.

At TypLAB[1] we use Happstack as our server back-end which works `pretty well', but we are sometimes a bit disappointed by it lack of matureness. The codebase is a bit messy and lacks some important features that you'll need when building `real applications'.

I feel that Haskell is the true candidate for being the perfect web language, but we still have a long way to go. We should just keep on playing with new ideas and abstractions until we all see the big picture. Some standards will arise eventually.

> Sincerely,
> Gour


Sincerely,

--
Sebastiaan Visser

[1] https://blog.typlab.com/