[erlang-questions] Erlang http servers

[Joe Armstrong]

On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <serge@REDACTED> wrote:
> Haven't had a need for an HTTP server in Erlang for a while since I last
> used inets-based http server five years back, and now examining what
> exists in public domain.
>
> The results are quite surprising - everyone who seems comfortable coding
> in Erlang, feels compelled to implement an HTTP server.  Previously we
> had only one contender to inets - yaws.  Now the landscape is quite a
> mouthful - inets, yaws, cowboy, musultin, mochiweb, etc.  As Steve
> Vinoski rightfully points out (*) this doesn't help to pull the blanket
> in all directions.  From personal experience with inets, I recall that
> once I figured out how to use it, it happened to be a very helpful and
> powerful HTTP library for building an application server.  So why don't
> all the authors of those wonderful alternative libraries just patch the
> inets to extend it with something they feel missing so that we only have
> one good and documented library to use as the common denominator?

I can think of several reasons why this does not happen:

 a) You have to distinguish between functional and non-functional behavior.
     All web-servers implement the same protocol (HTTP) - so they are
functionally
     equivalent - but their non-functional behavior is very different
- one server
     might be optimized for large numbers of short-lived sessions,
another for a few long-lived
     sessions. One might cache content, another not. So even though they are
     all http servers they have very different behaviour - this is good.

 b) Servers have two interfaces - the protocol interface (HTTP) and
the interface towards
     Erlang (the API if you like). As far as I can see most severs
have different Erlang APIs.
     This is bad.

c) Inets is shipped with OTP ie built and maintained by the OTP group.
This is not really
   "core business" as far as the OTP group is concerned, better for
everybody if non-core
   applications get taken over by third-part vendors.

d) As things mature - people want more in the way of "service" - ie
good documentation and the ability
   to buy support - the problem with software is not so much that of
writing it - which can be
   easy or difficult depending upon the problem but with the "burden of support"

Personally I'm quite happy with there being several different http
servers,  It gives me several to choose
from. No server in the world will do exactly what I want so they all
need tweaking in one way or another.

What I don't like is that all have different APIs - this make swapping
between severs a pain.
Some degree of standardization of the APIs necessary to setup and
manage the servers would be
highly desirable.

It would also be highly desirable to standardize the relationship
between a http uri and
and erlang function call.  For example


     http://some.host/erlcall?mod=foo&func=bar&arg1=111

means call foo:bar(...) on the server and return the value as html (or
something)

 Currently the http-server side of things seems ok - what I'm missing is the
entire user management cycle - password management, authentication, cookies,
forgotten passwords etc. - this needs far more than an http server, it needs
a persistent database, security and so on ...

Cheers

/Joe




> Serge
>
>
> (*) http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions