[erlang-questions] Erlang http servers
Mon Oct 1 16:30:25 CEST 2012
I don't agree with everything Joe writes below:
On 10/1/12, Joe Armstrong <> wrote:
> On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <>
>> 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 agree with Serge that it is somewhat unfortunate that there are so
where people write their own implementation of something we already
have included in
the Erlang/OTP distribution and doing this without even suggesting or
asking us if we could
incorporate some missing feature or improve the current implementation
in various ways.
I think it is better to try to improve the existing functionality
first and only if that is not feasible make another implementation
with a new API.
In Erlang/OTP we have keep strict compatibility with many of our APIs
which is both a strength and sometimes a burden (when we are not happy
with the old API) but there are mostly ways around that if there is
strong case for a change.
> 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
> 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
> 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.
Would be good if there was a kind of standardized API for HTTP-servers
> 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.
Joe is right reagarding core business in that there are not much use
of HTTP-servers in
products developed with Erlang inside Ericsson (who is financing ERlang/OTP) and
if used the requirements are not very demanding.
> 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
We still actively develop inets with its http client and server and I
am not sure that
all the reasons to develop alternatives still exist.
We are more than happy to receive contributions with bugfixes and new
I think it is of great value to have a relative complete functionality
in Erlang/OTP so that
the user can implement basic functionality without having to search
for separate implementations of, with unknown quality and completeness
at least for a beginner.
> 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
> means call foo:bar(...) on the server and return the value as html (or
> Currently the http-server side of things seems ok - what I'm missing is
> entire user management cycle - password management, authentication,
> forgotten passwords etc. - this needs far more than an http server, it
> a persistent database, security and so on ...
/Kenneth, Erlang/OTP Ericsson
>> erlang-questions mailing list
> erlang-questions mailing list
More information about the erlang-questions