[erlang-questions] Re: Web server structure: Rack

[Dmitrii Dimandt]

>> Actually, it's not entirely true for the web.
>> 
>> - There's ton of information being passed around in HTTP requests
>> - Parsing this information out is a tedious task and needs to be redone for every new web layer you wish to build
>> - Parsing multipart forms is PITA, see http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_multipart.erl and http://bitbucket.org/justin/webmachine/src/tip/src/webmachine_multipart.erl (see esp. the comment about how browsers are fun :) )
>> - Setting cookies correctly is PITA, see http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_cookies.erl
>> - You can't reliably write generic code that will run across all Erlang web servers, since every web server differs in how it presents information to your code and what it expects from your code
>> - Because of that you can't reliably abstract parts of your functionality (caching, setting etags etc., see e.g. http://rack.rubyforge.org/doc/Rack.html) into truly reusable pieces of code
> 
>    I agree with most of the points you have raised above (except the
> parsing of the HTTP protocol which is already done by the core Erlang
> modules). Indeed it is really hard to write a good (as in correct) web
> server, and even harder to write one that works with all the browsers.
> 


Well, parsing the protocol itself might be easy, but following it surely isn't :)  http://webmachine.basho.com/diagram.html

And webmachine is only available for mochiweb...


> 
>> Because of that a common web server interface is actually a blessing and, in my opinion, should be accepted more aggressively.
> 
>    Indeed such a <<common web server interface>> could be a
> <<blessing>> for the enterprise world, where you need something stable
> and reliable. But there is also a drawback: I remember (maybe I'm
> wrong because I'm not a web developer, but I've kept a close eye),
> that a few years ago (5 maybe?) the only usable (as in enterprise
> ready) web server was Apache (now we have LigHTTPD, Nginx, and of
> course Apache, thus not too much better in terms of diversity)...
> 
>    What I'm trying to say: a <<common web server interface [...] that
> should be accepted more aggressively>> leads to (framework) lock-in...
> 
> 
>> - Parsing multipart forms is PITA, see http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_multipart.erl and http://bitbucket.org/justin/webmachine/src/tip/src/webmachine_multipart.erl (see esp. the comment about how browsers are fun :) )
>> - Setting cookies correctly is PITA, see http://code.google.com/p/mochiweb/source/browse/trunk/src/mochiweb_cookies.erl
> 
>    Also we are missing a important point: web servers are not only
> for (user) web-pages. One important usage is also web-services (I'm
> not meaning WSDL or REST-like, but anything using HTTP as transport).
> And in the web-services case, usually there is no multi-part content,
> no cookies, even no caching (usually).
>    Thus in this case all the above mentioned features (caching, etc.)
> are useless and usually incur more overhead than needed.
> 
>    But in general I agree: in a production environment we need a
> stable, commonly accepted web-stack.
> 
>    Ciprian.
> 
> 
>    P.S.: I'm wondering about something: in a (user-centric) web
> environment isn't string (as in Unicode) support very important? And
> let's face it Erlang is not the most efficient string manipulation
> language. (Right?)


Well, it turns out that it's not such an issue after all. The only problem would be things like transliteration which can be done manually (see to_name in http://code.google.com/p/zotonic/source/browse/src/support/z_string.erl). And as NIFs become stable, someone will surely write an interface to ICU :)