Erlang http servers - Erlang Programming

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Message from discussion Erlang http servers
Received-SPF: pass (google.com: domain of erlang-questions-boun...@erlang.org designates 192.121.151.104 as permitted sender) client-ip=192.121.151.104;
MIME-Version: 1.0
In-Reply-To: <CAANBt-rz6A9Xdnv78=kdPWMQdZQ0N60J=wOx6DO22kG9Cju...@mail.gmail.com>
References: <5068B9B6.6070...@aleynikov.org>
 <CAANBt-rz6A9Xdnv78=kdPWMQdZQ0N60J=wOx6DO22kG9Cju...@mail.gmail.com>
Date: Mon, 1 Oct 2012 16:30:25 +0200
Message-ID: <CAOzgw92BwbNW6inti1fw6h6_xmwFd153HhuVMvjgCfd-anZ...@mail.gmail.com>
From: Kenneth Lundin <kenneth.lun...@gmail.com>
To: Joe Armstrong <erl...@gmail.com>
Cc: erlang-questi...@erlang.org
Subject: Re: [erlang-questions] Erlang http servers
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: erlang-questions-boun...@erlang.org
Sender: erlang-questions-boun...@erlang.org

I don't agree with everything Joe writes below:

On 10/1/12, Joe Armstrong <erl...@gmail.com> wrote:
> On Sun, Sep 30, 2012 at 11:29 PM, Serge Aleynikov <se...@aleynikov.org>
> 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-questi...@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
