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."<div><br>
</div><div>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.</div><div><br></div><div>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.  </div>
<div>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 <i>lingua franca.</i></div>
<div><br></div><div>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... :)</div>
<div><br></div>
<div>-mox<br><br><div class="gmail_quote">On Tue, Oct 2, 2012 at 10:37 AM, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>On 10/02/2012 05:52 PM, Serge Aleynikov wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with Joe that having a design of the HTTP server architecture<br>
included in OTP that would offer standardized internal API and allow<br>
developers to either replace selected functionality via providing<br>
callback modules or swap the HTTP servers easily would be a great plus.<br>
</blockquote>
<br></div>
This wouldn't have helped Cowboy, as one of the biggest difference is the use of binary instead of strings.<br>
<br>
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.<div>

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Diversity is good, but at some point it creates a burden for the user<br>
who needs to make a selection of an HTTP server for his project.<br>
</blockquote>
<br></div>
It doesn't!<div><br>
<br>
> Instead of solving the application-related problem, now the task becomes<br>
> studying several implementations to see which one offers a feature-set<br>
> best suited for the problem being solved, and the answer to that<br>
> question is not always straightforward.<br>
<br></div>
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.<br>


<br>
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.<br>


<br>
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.<div>

<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps a good initiative from the OTP team would be to spec out the<br>
open architecture of an HTTP server and welcome feedback from authors of<br>
current http libraries, so that the successor of inets would be flexible<br>
enough to accommodate building light-weight and heavy-weight HTTP<br>
servers based on the supported code base included in OTP?  This would<br>
also open a possibility of diversity for library writers<br>
replacing/enhancing parts to suit their needs.<br>
</blockquote>
<br></div>
More importantly, do people actually want that?<span><font color="#888888"><br>
<br>
-- <br>
Loïc Hoguin<br>
Erlang Cowboy<br>
Nine Nines<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a></font></span><div><div><br>
______________________________<u></u>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div>