As one of the first users of the Inets web server, I would like to point out that, at the time, making it Apache-compatible made
perfect sense. It was by no means obvious that it was the best
choice to use an Erlang-based web server in a telecom-class
product, and Apache was a strong contender.
Of course, it would have been nice to have been able to put
a lot of effort into the web server already from the start, but it was by no means a priority, as we had much bigger fish to fry with OTP. ;-)
The Inets HTTP server did it's job extremely well given our requirements. I cannot recall any issues - which is not to say that there weren't any, but that they were not serious enough to linger in my mind all this time.
The main challenge for us on the HTTP front was to create a framework that allowed us to design and maintain over 100
different web pages, with dynamic content, access control and
live SNMP hooks. *That* would have been something to contribute
to the Open Source community. After a wholesale rewrite in (I think) 1999, it was actually pretty nice, esp. compared to what
was needed and expected at the time.
BR,
Ulf W
On 3 Oct 2012, at 22:00, Ingela Andin wrote:
> Hi!
> I feel compelled to contribute on the topic of the hidden inets
> application. Once a upon a time someone in Ericsson wrote an http
> server that was very much inspired by Apache, which probably seemed
> sensible at the time but it does not feel like the erlang way of doing
> things. It was almost not document but used extensively by
> Ericsson projects, hence very hard to get rid of. ...
I think, it is a problem about HTTP, not about user contributions.
HTTP is an outstanding protocol. It is not yet-another-silly-protocol
like RTMP or LDAP.
It is a basic protocol for lots of projects, starting today. For
example, Dropbox. It could use rsync 10 years ago,
but today it is using only HTTP.
And it is a very complicated protocol that includes many modern
extensions, like websockets, etc.
This is why users require implementation which is very optimized and
fresh. It is really hard to write such a basic code of HTTP server,
that will fit all users requirements for next 3 years.
To understand it better, lets try to think: why there is no SIP + RTP
implementation in OTP? Why telecom platform doesn't include main
telecom protocol? I think, it is because it is almost impossible to
write such a SIP implementation, that will fit all needs.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
On Wed, Oct 3, 2012 at 10:28 PM, Max Lapshin <max.laps...@gmail.com> wrote:
> I think, it is a problem about HTTP, not about user contributions.
> HTTP is an outstanding protocol. It is not yet-another-silly-protocol
> like RTMP or LDAP.
> It is a basic protocol for lots of projects, starting today. For
> example, Dropbox. It could use rsync 10 years ago,
> but today it is using only HTTP.
> And it is a very complicated protocol that includes many modern
> extensions, like websockets, etc.
> This is why users require implementation which is very optimized and
> fresh. It is really hard to write such a basic code of HTTP server,
> that will fit all users requirements for next 3 years.
> To understand it better, lets try to think: why there is no SIP + RTP
> implementation in OTP? Why telecom platform doesn't include main
> telecom protocol?
Possibly for the same reason that apple doesn't release the
source code for OS-X in X-code :-)
/J
> I think, it is because it is almost impossible to
> write such a SIP implementation, that will fit all needs.
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
On Thu, Oct 4, 2012 at 12:43 AM, Joe Armstrong <erl...@gmail.com> wrote:
> Possibly for the same reason that apple doesn't release the
> source code for OS-X in X-code :-)
Yes, I haven't even though about it =)))
But indeed: what can be considered as a "rather generic" implementation of SIP?
What be useful for all?
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> On Thu, Oct 4, 2012 at 12:43 AM, Joe Armstrong <erl...@gmail.com> wrote:
>> Possibly for the same reason that apple doesn't release the
>> source code for OS-X in X-code :-)
> Yes, I haven't even though about it =)))
> But indeed: what can be considered as a "rather generic" implementation of SIP?
> What be useful for all?
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
"A fortunate turn of events allowed us to revive the early SIP exper-
iments, rewrite the software and experiment to find an optimal
architecture"
I consider that this is exactly what is happening now with http
servers in erlang.
Take a look at difference between yaws api, inets api and cowboy api.
They are really different even in such deep things:
* how many processes should serve http request?
* fully async parsing of http or using recv to synchronously parse it
* use return codes or explicit replying via reply module, etc.
This is an experimenting and it is hard to experiment when you need to
think about backward compatibility.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Part of the issue with inets is that at one's very
first look at the documentation it looks as though
nobody is bothering to maintain the documentation.
Inets is a container for Internet clients and servers.
Currently, an client and server, a TFPT client and server,
^^ s/an/a/
and a FTP client has been incorporated into Inets.
^^^ s/has/have/
The HTTP server and client is HTTP 1.1 compliant
^^ s/is/are/
as defined in 2616.
^ s//RFC /
...
Each client and server in inets is viewed as service.
^s//a /
At the last count, my Swedish vocabulary was a massive 20 words.
I couldn't even document how to boil water in Swedish.
So I'm not criticising anyone at Ericsson for writing this in
almost-English.
What I *am* saying is that practically every sentence on the
first page of text has something about it that's like a poke
in the eye to the point that for me it was less stressful to
find something else than to read this manual.
The text really needs to be revised by a native speaker of
English who is also a good writer.
Of course, getting that done professionally costs money, and
I paid, oh, it must be at least 0 dollars for Erlang...
Making the documentation sources and the tool chain available
means that it's possible now to contribute to people who need
HTTP (or FTP) services in Erlang by improving the inets
documentation, or it will be when the bug I reported (about
spaces dropping out) is fixed.
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> I think, it is a problem about HTTP, not about user contributions.
No the problem is not that we do not get user contributions, but the
lack of contributions
is a symptom of the problem that the for very long the non existing
documentation
of httpd resulted in that people did not understand how inets
webserver works and dismisses
it, not because it does not work well, but because they do not
understand how it works.
I still think the documentation is lacking but it is relativly much
better than before.
Considering HTTP and all things surrounding it I would still expect
there to be other webserves around. To compare there are people using
the odbc-application and contributing to it, but there are also a lot
of pople that think a more native API is what they need and roll thier
own. Point is the application has a life outside of Ericsson (in this
particulare case it
might not still be here if it had not).
> This is why users require implementation which is very optimized and
> fresh. It is really hard to write such a basic code of HTTP server,
> that will fit all users requirements for next 3 years
Inets tries to be a small core that should be easy to extend and
customize not a big bang webserver that comes with all the bells and
whistles. The big problem with the fist version of inets was not the
Apache approch but rather the lack of documentation. To make
improvments, extensions etc to an application you need to understand
how it is meant to work.
So point taken documentation needs further improvments.
> -----Original Message-----
> From: erlang-questions-boun...@erlang.org [mailto:erlang-questions-
> boun...@erlang.org] On Behalf Of Serge Aleynikov
> Sent: Sunday, September 30, 2012 16:29
> To: erlang-questi...@erlang.org
> Subject: [erlang-questions] Erlang http servers
> 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?
> Can someone please summarize this thread for me? If I am going to run a
> web server in Erlang, which one should I use?
Right now, Cowboy seems to be the favorite. The fellow who wrote MochiWeb
has said as much in past threads (that he would write MochiWeb like Cowboy
if he were to start today). The author of the misultin project shut it
down so that new development efforts could be focused on Cowboy and tools
that integrate with Cowboy.
WebMachine is still popular for writing RESTful web services, but note
that Cowboy provides this too.
Apache users who don't want to proxy to Cowboy probably want to use Yaws.
On Thu, Oct 4, 2012 at 9:24 AM, <tho...@oinksoft.com> wrote:
>> Can someone please summarize this thread for me? If I am going to run a
>> web server in Erlang, which one should I use?
> Right now, Cowboy seems to be the favorite.
Favorite among whom? This is a very broad statement that isn't broadly
true. There are many Yaws users out there, many Mochiweb users, and I
bet there are more than a few who still use Misultin.
IMO Cowboy is popular among folks who need a library-like HTTP server
and who also like to be leading edge, but not everyone falls into that
category, not even close. Also, there seems to be some ongoing rumor
that Yaws can't handle library-like HTTP apps, but that is entirely
untrue.
> WebMachine is still popular for writing RESTful web services, but note
> that Cowboy provides this too.
This statement is slightly confusing. The phrase "Cowboy provides
this" could be taken to mean "Cowboy provides Webmachine", which isn't
true. So just to be clear, what you really meant was that Cowboy
provides assistance for writing RESTful web services.
> Apache users who don't want to proxy to Cowboy probably want to use Yaws.
This is another unfair generalization. I've never been an Apache user,
yet I've used Yaws for everything from regular websites to embedded
systems and it's always given me just what I needed.
At about 11 years old and still going strong, Yaws is popular among
users who need a system they can count on to provide years of
production stability, backwards compatibility, and consistent support,
all while keeping up with the latest Web developments such as
streaming, long polling, WebSocket, and Server-Sent Events.
On Fri, October 5, 2012 7:53 am, Steve Vinoski wrote:
> Favorite among whom? This is a very broad statement that isn't broadly
> true. There are many Yaws users out there, many Mochiweb users, and I
> bet there are more than a few who still use Misultin.
I'm sorry, I made an unfair generalization. I should've been more
specific: Following this mailing list and discussions in the Freenode
channel for some time, it seems to me that the Cowboy project has a great
deal of momentum. This is not to say that the other tools are somehow
unsuitable or will all die out.
I certainly didn't intend to slight Yaws, which is a perfectly stable,
capable web server, as are the other projects. Perhaps I should have
phrased my recommendation in terms of what the others are good for rather
than comparing them to Cowboy: You can't go wrong with Yaws or MochiWeb
which are proven, stable servers. WebMachine is notably well-suited for
writing RESTful services and focuses on HTTP compliance. Misultin is a
good product but is no longer actively developed or maintained by the
original author, so it is a riskier choice.
This thread is still going? How long till it is the longest thread ever on
the mailing list? (I suspect those are in the 100s though actually, haha).
But how has this not just ended with the understanding:
a) Yaws for some, can be embedded or used like a stand alone web server and
is known to be stable, fast and production ready
b) Cowboy for http library in your app and you like bleeding edge and a
smaller dependency -- and now even smaller in it self but requires ranch
c) Ellis for those who don't care to support http
d) Whatever makes you happy, maybe write your own!
And in my opinion Cowboy REST is now a much better Webmachine than
Webmachine, due to some changes around handling POST and a few other things.
On Fri, Oct 5, 2012 at 8:04 AM, Thomas Allen <tho...@oinksoft.com> wrote:
> On Fri, October 5, 2012 7:53 am, Steve Vinoski wrote:
> > Favorite among whom? This is a very broad statement that isn't broadly
> > true. There are many Yaws users out there, many Mochiweb users, and I
> > bet there are more than a few who still use Misultin.
> I'm sorry, I made an unfair generalization. I should've been more
> specific: Following this mailing list and discussions in the Freenode
> channel for some time, it seems to me that the Cowboy project has a great
> deal of momentum. This is not to say that the other tools are somehow
> unsuitable or will all die out.
> I certainly didn't intend to slight Yaws, which is a perfectly stable,
> capable web server, as are the other projects. Perhaps I should have
> phrased my recommendation in terms of what the others are good for rather
> than comparing them to Cowboy: You can't go wrong with Yaws or MochiWeb
> which are proven, stable servers. WebMachine is notably well-suited for
> writing RESTful services and focuses on HTTP compliance. Misultin is a
> good product but is no longer actively developed or maintained by the
> original author, so it is a riskier choice.
<tristan.slough...@gmail.com> wrote: > This thread is still going? How long till it is the longest thread ever on > the mailing list? (I suspect those are in the 100s though actually, haha).
> But how has this not just ended with the understanding:
> a) Yaws for some, can be embedded or used like a stand alone web server and > is known to be stable, fast and production ready > b) Cowboy for http library in your app and you like bleeding edge and a > smaller dependency -- and now even smaller in it self but requires ranch > c) Ellis for those who don't care to support http > d) Whatever makes you happy, maybe write your own!
> And in my opinion Cowboy REST is now a much better Webmachine than > Webmachine, due to some changes around handling POST and a few other things.
At least on 0.6.0 cowboy had unexpectedly horrible performance issues handling big POST requests, like discovered by my colleague[1]. Not sure if this is now fixed. So *always* measure. Always.
> At least on 0.6.0 cowboy had unexpectedly horrible performance issues > handling big POST requests, like discovered by my colleague[1]. Not > sure if this is now fixed. So *always* measure. Always.
Does Cowboy work on Windows? I ask because I went to download it and give it a whirl, but the first line of the Quick Start section says to use Rebar, which does not work on Windows. Please advise. Thank-you.
> -----Original Message----- > From: erlang-questions-boun...@erlang.org [mailto:erlang-questions- > boun...@erlang.org] On Behalf Of Loïc Hoguin > Sent: Friday, October 05, 2012 09:29 > To: Motiejus Jakštys > Cc: erlang-questi...@erlang.org > Subject: Re: [erlang-questions] Erlang http servers
> On 10/05/2012 04:23 PM, Motiejus Jakštys wrote: > > At least on 0.6.0 cowboy had unexpectedly horrible performance issues > > handling big POST requests, like discovered by my colleague[1]. Not > > sure if this is now fixed. So *always* measure. Always.
It hasn't been tested on Windows, but it should work, with possibly a few easily fixed bugs in cowboy_static (that's the only Cowboy code dealing with files).
I have no idea how to build an Erlang project on Windows.
> Does Cowboy work on Windows? I ask because I went to download it and give it a whirl, but the first line of the Quick Start section says to use Rebar, which does not work on Windows. Please advise. Thank-you.
> Cheers,
> DBM
>> -----Original Message----- >> From: erlang-questions-boun...@erlang.org [mailto:erlang-questions- >> boun...@erlang.org] On Behalf Of Loïc Hoguin >> Sent: Friday, October 05, 2012 09:29 >> To: Motiejus Jakštys >> Cc: erlang-questi...@erlang.org >> Subject: Re: [erlang-questions] Erlang http servers
>> On 10/05/2012 04:23 PM, Motiejus Jakštys wrote: >>> At least on 0.6.0 cowboy had unexpectedly horrible performance issues >>> handling big POST requests, like discovered by my colleague[1]. Not >>> sure if this is now fixed. So *always* measure. Always.
On Fri, Oct 5, 2012 at 4:36 PM, David Mercer wrote:
> Does Cowboy work on Windows? I ask because I went to
> download it and give it a whirl, but the first line of the Quick
> Start section says to use Rebar, which does not work on Windows.
> Please advise. Thank-you.
rebar does work and is used by Erlang developers on Windows.
What specifically didn't work for you? Did you use rebar.cmd?
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
On 5 October 2012 16:36, David Mercer <dmer...@gmail.com> wrote:
> Does Cowboy work on Windows? I ask because I went to download it and give it a whirl, but the first line of the Quick Start section says to use Rebar, which does not work on Windows. Please advise. Thank-you.
Just to confirm, rebar *does* work on Windows, even for compiling
NIFs. Obviously the C code needs to support an appropriate compiler in
the first place, but that's not rebar's fault. So far I have built via
rebar snappy, ejson, jiffy, erica, and a whole plethora of other tools
& projects, without needing a special unix shell, just erlang & rebar.
Many thanks to Basho & Tuncer for making that possible.
Loïc, I'll give cowboy a whirl on Windows sometime next week & will
send an issue or patch if reqd.
> -----Original Message----- > From: Dave Cottlehuber [mailto:d...@jsonified.com] > Sent: Friday, October 05, 2012 10:37 > To: David Mercer; Loïc Hoguin; Motiejus Jakštys; erlang- > questi...@erlang.org > Subject: Re: [erlang-questions] Erlang http servers
> On 5 October 2012 16:36, David Mercer <dmer...@gmail.com> wrote: > > Does Cowboy work on Windows? I ask because I went to download it and > give it a whirl, but the first line of the Quick Start section says to use Rebar, > which does not work on Windows. Please advise. Thank-you.
> Just to confirm, rebar *does* work on Windows, even for compiling NIFs. > Obviously the C code needs to support an appropriate compiler in the first > place, but that's not rebar's fault. So far I have built via rebar snappy, ejson, > jiffy, erica, and a whole plethora of other tools & projects, without needing a > special unix shell, just erlang & rebar. > Many thanks to Basho & Tuncer for making that possible.
> Loïc, I'll give cowboy a whirl on Windows sometime next week & will send an > issue or patch if reqd.
I am currently using Cowboy, built with rebar, on Windows 7, 64Bit. I did not have to do anything special to build. And, except for issues of my own creation, have had no problems; although I have on,y used the most basic http_handler to date.
Sent from my iPad
On Oct 5, 2012, at 12:47 PM, "David Mercer" <dmer...@gmail.com> wrote:
> I'll give it another whirl. Tried it about a year ago and it didn't work. Rebar, that is; haven’t tried Cowboy yet.
> I'll report back on my experiences so that I don't leave you hanging.
> Cheers,
> DBM
>> -----Original Message----- >> From: Dave Cottlehuber [mailto:d...@jsonified.com] >> Sent: Friday, October 05, 2012 10:37 >> To: David Mercer; Loïc Hoguin; Motiejus Jakštys; erlang- >> questi...@erlang.org >> Subject: Re: [erlang-questions] Erlang http servers
>> On 5 October 2012 16:36, David Mercer <dmer...@gmail.com> wrote: >>> Does Cowboy work on Windows? I ask because I went to download it and >> give it a whirl, but the first line of the Quick Start section says to use Rebar, >> which does not work on Windows. Please advise. Thank-you.
>> Just to confirm, rebar *does* work on Windows, even for compiling NIFs. >> Obviously the C code needs to support an appropriate compiler in the first >> place, but that's not rebar's fault. So far I have built via rebar snappy, ejson, >> jiffy, erica, and a whole plethora of other tools & projects, without needing a >> special unix shell, just erlang & rebar. >> Many thanks to Basho & Tuncer for making that possible.
>> Loïc, I'll give cowboy a whirl on Windows sometime next week & will send an >> issue or patch if reqd.
