[web-devel] Re: [Haskell-cafe] HSGI: Haskell Server Gateway Interface

[Manlio Perillo]

Felix Martini ha scritto:
> [Original discussion in haskell-cafe:
> http://www.haskell.org/pipermail/haskell-cafe/2009-February/055270.html]
> 
> Manlio Perillo:
>> Here are the problems:
>>
>> 1) supported HTTP methods are fixed, since you use a custom data type
> 
> (Btw. It is not my proposal, Johan Tibell has written it. I'll mail
> him to notify him about this discussion.)
> 
> I agree with that. In my own framework prototype i have
> 
> data HttpMethod = OPTIONS
>                           | GET
>                           | HEAD
>                           | POST
>                           | PUT
>                           | DELETE
>                           | TRACE
>                           | CONNECT
>                           | Extension String
>     deriving (Eq, Show)
> 

+1

>> 2) no support for other possible CGI variables
>>   (or simply custom variables: I use the environ dictionary to store
>>   application configuration, and I think it is a great thing).
> 
> A user dictionary / association list could be useful. A Trie is
> probably faster than a Map so i am not sure if the Map type should be
> used. Could also be implemented by the frameworks themselves.
> 

Let the framework handle the configuration data is what most of the 
Python web framework do.

I personally prefer to have the configuration data stored in the environ 
dictionary.


>> 3) No support for optimized file serving, like with WSGI file_wrapper
> 
> Would be nice to have provided it is cross-platform.
> 

It needs not to be cross platform.
See how WSGI file_wrapper is implemented.

You just need to pass to the server a file Handle (and optionally an 
offset).
If the server does not support sendfile, or memory mapped files, it can 
just iterate over the file and sends each chunk to the client.

>> 4) No support for keeping "complex" state (like database connection) in
>>   the environ.
>>
>>   I have read some examples with CGI package, where a custom monad
>>   transformer is used.
>>   I'm not sure if this solution is flexible and "scalable".
> 
> This should be a task for the framework itself. Using a ReaderT or
> StateT transformer is very common in Haskell.
> 

How is this "composable"?

Let's assume we have a "big" application.
As an example an application with multiple url dispatchers:

/a
    -> /ax
    -> /ay
/b
    -> /bx
    -> /by


Of course I would like to setup the connection on only one place.

Storing the connection in the WAI environment is handy.
Of course you still need a ReaderT or StateT transformer, but your state 
is all in one place.

Can you post an example? Thanks.

>> 5) I can't find documentation about the type of the response.
>>   It is rather clear that it is
>>      (ByteString, [(ByteString, ByteString)], Enumerator)
>>
>>   but this should be documented somewhere.
> 
> It's a wiki so feel free to change it or add more documentation.
> 
> 
> About the enumerator, using it is indeed debatable because it is not
> immediately obvious how it works, but i haven't seen anything for
> Haskell that works better. Like other haskellers have said lazy
> bytestrings with IO is asking for trouble. I have been bitten by it
> myself and it is hard to debug. Imho lazy bytestrings are only useful
> when the data generator is a pure function.
> 

Well, I find the enumerator "story" quite strange.
It is the best idea available, it is "quite old", however I can't see it 
largely in use.
There is not even a chapter about it in the Real World Haskell.

> Regards,
> Felix
> 


Regards  Manlio