[erlang-questions] Erlang http servers

[Kenneth Lundin]

I don't agree with everything Joe writes below:

On 10/1/12, Joe Armstrong <erlang@REDACTED> wrote:
> 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 agree with Serge that it is somewhat unfortunate that there are so
many initiatives
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
> 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.
Would be good if there was a kind of standardized API for HTTP-servers
and clients.
>
> 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
> support"
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
functionality.

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
>
>
>      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
>
>
/Kenneth, Erlang/OTP Ericsson
>
>> 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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>