[erlang-questions] Erlang http servers

[Mike Oxford]

I would even go so far as to propose that almost every single Erlang
project, for the foreseeable future will want an HTTP service.  I would
even extend this to "most project in any realm in any language."

Reason:  Even if you're not providing an external service, having a
web-status console, admin or REST-based health/monitoring/whatever port has
a whole lot of value.

Right now, if you want external services you have to meld
server+protocol+client.  The HTTP's strongest suit is that, just like
javascript, it's ubiquitous.  It may not be optimal, but it's everywhere
and it's easy.
Would I prefer a world built on client-side(browser!) Erlang, a
length-prefixed binary protocol and real sockets (instead of websocket
silliness)? Hell yes.  But we don't have that, and likely won't anytime
soon, so HTTP+javascript continues to be the *lingua franca.*

Having too many options is a Bad Thing<tm>, IMO.  Erlang is already enough
of a 'big scary monster in the dark' for a lot of people.  If we had a
unified, documented, packaged and turnkey solution withing the stdlib so
that users could 'drop in and go' it would increase uptake as people at
least explored it.  The are more web-coders than ever, many with just
enough knowledge to be dangerous.  Apple vs PC back in the day --- snag all
of the low-hanging cheap fruit of PC clones instead of insisting on the
white-ivory-tower and then achieve market dominance (which is then yours to
lose/squander at your leisure... :)

-mox

On Tue, Oct 2, 2012 at 10:37 AM, Loïc Hoguin <essen@REDACTED> wrote:

> 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
>
> ______________________________**_________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/**listinfo/erlang-questions<http://erlang.org/mailman/listinfo/erlang-questions>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121002/0162bdc1/attachment.htm>