[erlang-questions] Erlang http servers

[Loïc Hoguin]

On 10/02/2012 05:52 PM, Serge Aleynikov wrote:
> I agree with Joe that having a design of the HTTP server architecture
> included in OTP that would offer standardized internal API and allow
> developers to either replace selected functionality via providing
> callback modules or swap the HTTP servers easily would be a great plus.

This wouldn't have helped Cowboy, as one of the biggest difference is 
the use of binary instead of strings.

There's another solution, which is to write wrappers for other APIs, for 
example mochicow allows Mochiweb applications to use Cowboy under the 
hood without having to change their code. This means that the switch can 
be progressive instead of being brutal like a direct code switch.

> Diversity is good, but at some point it creates a burden for the user
> who needs to make a selection of an HTTP server for his project.

It doesn't!

 > Instead of solving the application-related problem, now the task becomes
 > studying several implementations to see which one offers a feature-set
 > best suited for the problem being solved, and the answer to that
 > question is not always straightforward.

Erlang is wonderful in that it allows you to write your application 100% 
HTTP-free, and then write another application for the HTTP layer that 
will be a thin layer running alongside your application. The 
communication layer can be separate from the business logic.

If you go that way then your application's code isn't dependent on the 
transports used at all, and you can easily switch servers, change 
protocols, serialization formats or anything in your HTTP layer without 
this impacting your application in any way.

For example, when SPDY support will be added to Cowboy, only the HTTP 
layer will require a change to make use of it (start_http, which only 
does HTTP, can be replaced by start_spdy, which does SPDY or HTTP 
depending on client capabilities). The application behind it shouldn't 
have to care about that.

> Perhaps a good initiative from the OTP team would be to spec out the
> open architecture of an HTTP server and welcome feedback from authors of
> current http libraries, so that the successor of inets would be flexible
> enough to accommodate building light-weight and heavy-weight HTTP
> servers based on the supported code base included in OTP?  This would
> also open a possibility of diversity for library writers
> replacing/enhancing parts to suit their needs.

More importantly, do people actually want that?

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu