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

[Ciprian Dorin, Craciun]

On Mon, Jan 11, 2010 at 9:53 AM, Dmitrii Dimandt <dmitriid@REDACTED> wrote:
>
>> On Sun, Jan 10, 2010 at 4:46 PM, Steve Davis
>> <steven.charles.davis@REDACTED> wrote:
>>>
>>> What's wrong with building on inets? Why do we reinvent the web layer
>>> for OTP so often?
>>>
>>> BTW I am genuinely extremely interested in answers to these questions.
>>
>>    Maybe there's nothing wrong with inets.
>>
>>    But why do we reinvent the web layer? :)
>>    * it's a nice and easy task (well known, simple and useful
>> protocol) to write as one of your first OTP applications; (I wrote an
>> Gopher server as my first application; and I've also written my own
>> (almost throw-away) web server;)
>>    * it's fun to write a web stack that works **exactly** the way
>> **you** want; (or at least you think you want and then you change your
>> mind ;) )
>>    * it's damn easier than in other languages; (no threading /
>> multi-process / scalability issues);
>>
>>    Hope others agree and add other motives.
>>    Ciprian.
>
>
> 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.


> 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?)