[erlang-questions] Misultin EOL

[Roberto Ostinelli]

Dear list,

Misultin development has been discontinued.

There currently are three main webserver libraries which basically do similar things:

• Mochiweb
• Cowboy
• Misultin

Especially since the recent heavy development of Cowboy's HTTP server, I believe there is way too much duplication of efforts going on here. This is why Misultin's current 'state of the art' has been frozen in the latest tag, v0.9, to support all the companies currently using Misultin in their production environment. I'm here to provide help, if needed, in moving away from it. Thus, this server should be robust and stable enough to continue serving your needs for some time.

Instead of letting this library stand on github without notice, and getting developers still use this project, I have preferred to explicitly state to gradually move away from it, so that efforts can be concentrated around one server library only. It's hard enough to let one 'child' like this one go, but I believe it's best for the whole Erlang community. There are many ways to try to help each other in the community, I believe this decision is now for the better.

Mochiweb has been around the block for a while and it's proven solid in production, I can only recommend it for all basic webserver needs you might have. Cowboy has a very interesting approach since it allows to use multiple TCP and UDP protocols on top of a common acceptor pool. It is a very modern approach, is very actively maintained and many projects are starting to be built around it.

I'll personally concentrate my efforts around Cowboy, simply because the projects I'm involved in often require multiple procotols. I really hope that it'll live up to the expectations that I'm putting into this.

Thank you to everyone that has been supporting Misultin in these years. Hopefully its code usability, which I still believe to be unmatched (well, I have developed it so how could I feel differently about this ^^_), will provide inspiration for some library interfaces.

Best to you all,

r.

[Loïc Hoguin]

Hello.

I'm sad to see Misultin go, this was in my opinion the only other
project that had enough momentum to introduce innovation in Erlang web
servers. Even though there certainly was duplication happening, there
was also original and interesting components (some which landed in
cowboy, and vice versa). I almost ended up going for Misultin
originally, but I wanted a Misultin+Webmachine+binaries (for the most
part), a combination that didn't exist at the time.

I'm always available by email or on #erlounge on freenode if people need
help with moving to Cowboy. From what I've seen so far the task isn't
too complicated. If anything is missing in Cowboy, please open a ticket.

For usability concerns, Spawngrid did the following parse transform that
helps you deal with the many Req variables. I don't use it, but it seems
to work great for them.

https://github.com/spawngrid/seqbind

Thank you Roberto for everything you have done so far and I hope we can
continue to work together on making Erlang HTTP stacks the best ones in
the world.

On 02/16/2012 04:56 PM, Roberto Ostinelli wrote:
> Dear list,
>
> Misultin development has been discontinued.
>

> There currently are three main webserver /libraries/ which basically do
> similar things:
>
> * Mochiweb <https://github.com/mochi/mochiweb>
> * Cowboy <https://github.com/extend/cowboy>
> * Misultin <https://github.com/ostinelli/misultin>

>
> Especially since the recent heavy development of Cowboy's HTTP server, I
> believe there is way too much duplication of efforts going on here. This
> is why Misultin's current 'state of the art' has been frozen in the
> latest tag, v0.9

> <https://github.com/ostinelli/misultin/tree/misultin-0.9>, to support

> all the companies currently using Misultin in their production
> environment. I'm here to provide help, if needed, in moving away from
> it. Thus, this server should be robust and stable enough to continue
> serving your needs for some time.
>
> Instead of letting this library stand on github without notice, and
> getting developers still use this project, I have preferred to
> explicitly state to gradually move away from it, so that efforts can be
> concentrated around one server library only. It's hard enough to let one
> 'child' like this one go, but I believe it's best for the whole Erlang
> community. There are many ways to try to help each other in the
> community, I believe this decision is now for the better.
>

> *Mochiweb* has been around the block for a while and it's proven solid

> in production, I can only recommend it for all basic webserver needs you

> might have. *Cowboy* has a very interesting approach since it allows to

> use multiple TCP and UDP protocols on top of a common acceptor pool. It
> is a very modern approach, is very actively maintained and many projects
> are starting to be built around it.
>
> I'll personally concentrate my efforts around Cowboy, simply because the
> projects I'm involved in often require multiple procotols. I really hope
> that it'll live up to the expectations that I'm putting into this.
>
> Thank you to everyone that has been supporting Misultin in these years.

> Hopefully its *code usability*, which I still believe to be unmatched

> (well, I have developed it so how could I feel differently about this
> ^^_), will provide inspiration for some library interfaces.
>
> Best to you all,
>
> r.
>
>
>

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Tristan Sloughter]

For usability concerns, Spawngrid did the following parse transform that helps you deal with the many Req variables. I don't use it, but it seems to work great for them.

   https://github.com/spawngrid/seqbind

Also checkout Erlando from RabbitMQ and the State Monad for dealing with this pattern. https://github.com/rabbitmq/erlando

Tristan 

[Zabrane Mickael]

Sad news Roberto.

Anyway, thousands thanks for Misultin and hope you'll be still present to help the community (if needed).

Regards,

Zabrane

_______________________________________________

[Michael Truog]

Hi,

I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided. I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage. A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ . How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)? Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?

So, this change just leaves me with a bunch of questions that have no clear answers available. It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language. Thank you for your efforts on Misultin!

Thanks,
Michael

[Steve Vinoski]

On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjt...@gmail.com> wrote:
> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?

I'm not interested in flames either, but I am interested in facts.
Please back up your assertion by posting your meaningful benchmarks
that prove that Yaws is lacking in performance.

thanks,
--steve

[Jesse Gumm]

Not to state the obvious or anything, but Misultin is open source, so
someone could always step up to the plate and become the *official*
fork.

There will still be efforts to support Misultin: Chicago Boss uses it,
and barring some serious arguments against it, I'll still be adding
misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0
release.

So while it's unfortunate that Roberto is stepping away from Misultin
development, that doesn't mean it's necessarily dead - someone can
always take over.

-Jesse

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[Roberto Ostinelli]

I sure am. I just believe this is actually my best way to be around, i.e. by trying to push towards a common great lib.

r.

[Roberto Ostinelli]

On Thu, Feb 16, 2012 at 12:50 PM, Michael Truog <mjt...@gmail.com> wrote:

Hi,

I am very concerned about the fact Misultin will no longer be developed, mainly because I don't see how cowboy has been able to provide the same performance and stability Misultin has provided.  I understand there has been a great push for people to use cowboy, but I think it really requires loadtest result comparisons with Misultin to drive more serious usage.  A good way to start would be to show that cowboy can surpass or at least be on-par with Misultin in a benchmark similar to http://www.ostinelli.net/a-comparison-between-misultin-mochiweb-cowboy-nodejs-and-tornadoweb/ .  How can we compare cowboy and Misultin stability (i.e., for how long has cowboy been stable in production)?  Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?

So, this change just leaves me with a bunch of questions that have no clear answers available.  It is sad that we are losing stability due to hype, which seems like an uncommon trend among Erlang, but I assume this is more of a comment on the community rather than the language.  Thank you for your efforts on Misultin!

Thanks,
Michael

hi michael,

as stated in that old benchmark, please do not take wrong conclusions out of it. there's nothing in there which talks about stability and other things. i'm happy that i've published because it has brought *a lot* of attention to erlang, but i probably wouldn't do it again: benchmarks like this are probably more confusing than anything else.

i'm not going for 'hype', but tend to be a little realistic. i've been developing misultin mainly by myself with the support of the community. cowboy has had a fast adoption and lot of developer which i believe to be very good are actively and jointly working on it.

i'm obviously running misultin in production since i've built it because i needed it: i'm simply gradually gonna consider cowboy for my new projects.

r.

[Roberto Ostinelli]

On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm <gu...@sigma-star.com> wrote:

Not to state the obvious or anything, but Misultin is open source, so
someone could always step up to the plate and become the *official*
fork.

There will still be efforts to support Misultin: Chicago Boss uses it,
and barring some serious arguments against it, I'll still be adding
misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0
release.

So while it's unfortunate that Roberto is stepping away from Misultin
development, that doesn't mean it's necessarily dead - someone can
always take over.

-Jesse

hi jesse,

please don't suggest that. while i cannot avoid someone doing so, i could have kept maintaing misultin myself. as i said, it has been a hard decision.

my intent here is to avoid duplication of efforts, both for the contributors of the community (often reporting the same bugs in both repositories) and for the developers, which now have an hard time in deciding which way to go.

i just wanted to clear the way for a single webserver library, and cowboy seems to have much more developer time to actually maintaining it.

r.

[Michael Truog]

That may be a common reason to avoid providing any public benchmarks, it may never be a diplomatic thing to do, since it is raw results.  The interpretation of the results is always dependent on the individual that is doing the decision making.  However, the potential for an individual to misinterpret the results does not seem to be good justification for not posting performance information.  Keeping performance information private, helps to limit innovation, only encouraging stagnation.  Having a good idea of how HTTP servers compare is very beneficial, to help reduce latency, support more connections, and support more internal computation latency.... so, it helps us push limits.  I understand you may not want to do benchmarks like that in the future, but I think it would be a shame to not have more recent benchmark results that can provide a more logical guide for our decision making when we consider the strengths and weaknesses of the various Erlang HTTP servers (and their improvements over what is available without Erlang).

- Michael

[Michael Truog]

On 02/16/2012 01:17 PM, Steve Vinoski wrote:
> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjt...@gmail.com> wrote:
>> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?
> I'm not interested in flames either, but I am interested in facts.
> Please back up your assertion by posting your meaningful benchmarks
> that prove that Yaws is lacking in performance.
>
> thanks,
> --steve

It is unfair to say that yaws does not perform like misultin and I do not have data to make that statement. When I think of performance, I am also thinking of software development performance for modifying, extending, and using the code-base. Yaws has lacked support once mochiweb was available because of some fragmentation within the community. From what I have seen, yaws chooses not to focus on performance, and has never intended to do so in the past, so it is unclear whether it would be able to maintain its performance in the future, if it received more support (based on http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/). So, that was misleading for me to say, since you are probably correct that misultin is on par with yaws, though there are no public results to show that. With yaws the concern seems to be more about the code being regarded as legacy, not actively developed, and not modular (and whatever other reasons that seemed to make mochiweb
appear necessary). I say this knowing that you are currently the main maintainer of the code-base. These are just the impressions I have had from being within the Erlang community for a few years.

- Michael

[Loïc Hoguin]

I would have loved to have more benchmarks but of all the ones I've
heard about Cowboy so far none have been published (besides Roberto's).

Benchmarks are unfortunately often misunderstood and subject to flame
wars as was pointed out, but also hype. There's also the fact that not
all applications have the same requirements. Even if Cowboy was good
enough for 90% of applications, there'd still be a need for other kinds
of servers (same goes for other servers).

I can throw a few numbers if you want, however. A couple months ago
someone did a websocket benchmark on an Amazon EC2 instance and measured
Cowboy to take 11GB of memory with 500K idle connections. Then they
simulated the workload their application would take and after ironing an
issue out it ended up still working with 500K working connections. They
tested with more connections but I don't know the details there.

I myself had Cowboy running in production with no issue for a few months
now. I know various companies using it in different domains. I still
consider it beta and always warn people about it but this doesn't seem
to slow its adoption.

I can also say that Cowboy will take a central part in a few major
projects in the near future, though I can't say more than that at this time.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines

[Steve Davis]

Hi Roberto,

I'm a bit confused by this whole thread...

I'm agreeing with Jesse that since Misultin is open source, it's not
really in your control to "stop development" if the interest is there
elsewhere to push it on?

I'm also agreeing with Steve that I've not seen any demonstration that
yaws is somehow "lacking",

For me, the last interesting benchmark that demonstrated anything
graspably real was "yaws vs apache".

A really interesting benchmark for today's "web server" would be, if
someone were willing to engage in a non-trivial effort, to make a
comparison of a full-fledged web application with full session
management and routing capabilities. Note that this would truly test
the appropriateness of the server's http APIs as well as the base
response. That kind of benchmark, for me, would seem more appropriate
and useful according to the epoch.

Best regards,
/s

[Barco You]

>my intent here is to avoid duplication of efforts, both for the contributors of the community (often reporting the same bugs in both repositories) and for the developers, which now have an hard time in deciding which way to go.

>i just wanted to clear the way for a single webserver library, and cowboy seems to have much more developer time to actually maintaining it.

What's the logic behind forgoing a better one to support another with the purpose of avoiding duplicate efforts? Why not contributors come to help migrate the productions on those over-hyped frameworks to on the proven-best one?

No matter how, I like Misultin very much for its high performance, simplicity and advanced concepts. If it would really go I would be very sad and I believe many others in this community too.

Let's find a better way to contribute to our community better!

Regards,

Barco

[Michael Truog]

I understand that for your own specific use, you would prefer to benchmark the complete stack, which is completely reasonable. However, the goal is avoiding subjective judgments on complex technological decisions by reducing the testing to smaller components. The "yaws vs apache" benchmark is probably the oldest benchmark that exists, showing results with an Erlang HTTP server. The misultin benchmark is the best in the absence of other loadtest results, but I agree it is unfortunate that it wasn't more serious with client machines driving the test with something like Tsung. If you ignore that, the fact it was able to show relative performance was interesting.

Adding more complexity to the tests, when you bring in other components seems like it would make the test less useful, unless the Erlang components are part of someone's favorite "web framework" bundle. Then that just becomes a sales-pitch. I like the idea of having a more objective guide as to which Erlang HTTP server should be used, or how the decisions compare to non-Erlang HTTP servers. Those results then can help guide development decisions and simulate more innovation.

On 02/16/2012 06:09 PM, Steve Davis wrote:
> For me, the last interesting benchmark that demonstrated anything
> graspably real was "yaws vs apache".
>
> A really interesting benchmark for today's "web server" would be, if
> someone were willing to engage in a non-trivial effort, to make a
> comparison of a full-fledged web application with full session
> management and routing capabilities. Note that this would truly test
> the appropriateness of the server's http APIs as well as the base
> response. That kind of benchmark, for me, would seem more appropriate
> and useful according to the epoch.

_______________________________________________

[Edmond Begumisa]

Hi,

I have a small quibble (not trying to flame here), but isn't a comparison
between Yaws and Mutlisin a case of apples and oranges?

From a developer's perspective, Yaws is a webserver in the Apache+PHP
sense or IIS+.Net sense. Mutlisin (Mochiweb/Cowboy) are web server
libraries in the libmicrohttpd sense. Nitrogen, Erlang-web and Erlyweb are
web-frameworks in the Django/CakePHP sense. While webmachine is uniquely
on its own.

Yaws is about *serving* dynamic and static *content*? You'd consider using
Cowboy & Co' to develop "a yaws" if you were starting a yaws-like project
afresh in 2012. While you'd consider using yaws to develop a new
django-like framework for Erlang.

I'm yet to come across an Erlang web-server that is in the Yaws category
that has it's features and thoughtful design. I know of only Inets that's
also in this category.

So I always find it curious when Yaws is lumped into discussions where
it's strengths and focus don't fit at all.

Addressing some of your concerns:

Modularity - If you think of yaws as a web-application server that never
goes down and can run many applications, you'd find that it's very very
modular (appmonds/yapps). If it's modularity of the code-base itself that
your referring to, well, it doesn't look bad to me. I learned Erlang
largely by reading Yaws source code.

Usability - Development with yaws is the reverse of the popular web-libs.
You use yaws to "serve", cache, log and session manage one or more of your
web-apps (dynamic and static content) as opposed to using
Mutlisin/Mochiweb/Cowboy to write a web-app that serves, caches, and logs
itself and manages it's own sessions.

(In)activity - I personally haven't found many features that I've wanted
to be added to yaws itself, so it could be a case of feature saturation
rather than an under-developed legacy code-base. Most things that don't
exist, you can use from your app code without it being in yaws coz of the
way it's designed. For instance, I don't much like yaws' dynamic content
creation features (ehtml/ssi/yssi). Instead, I frequently use the ErlTL
template module from Erlyweb (without erlyweb).

That said, sometimes, for some projects, I find yaws overkill and reach
for one of the newer light webserver libs (usually when the app needs to
expose a simple web-API). But for most web projects with lots of content
(and where development time is scarce), I find using those libs would have
me duplicating a lot of the great work already done in yaws, so I reach
for yaws instead.

- Edmond -

On Fri, 17 Feb 2012 10:06:44 +1100, Michael Truog <mjt...@gmail.com>
wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Edmond Begumisa]

On Fri, 17 Feb 2012 13:09:45 +1100, Steve Davis
<steven.cha...@gmail.com> wrote:

> Hi Roberto,
>
> I'm a bit confused by this whole thread...
>

Me too!

> I'm agreeing with Jesse that since Misultin is open source, it's not
> really in your control to "stop development" if the interest is there
> elsewhere to push it on?

But he is basically the only guy developing it. Practically speaking, if
he declares to users "move to something else", the project is unlikely to
recover. Most people are unlikely to argue with the developer and persist.

>
> I'm also agreeing with Steve that I've not seen any demonstration that
> yaws is somehow "lacking",
>
> For me, the last interesting benchmark that demonstrated anything
> graspably real was "yaws vs apache".
>
> A really interesting benchmark for today's "web server" would be, if
> someone were willing to engage in a non-trivial effort, to make a
> comparison of a full-fledged web application with full session
> management and routing capabilities. Note that this would truly test
> the appropriateness of the server's http APIs as well as the base
> response. That kind of benchmark, for me, would seem more appropriate
> and useful according to the epoch.
>

I agree, there are too may apples and oranges comparisons in these
discussions.

- Edmond -

> Best regards,
> /s
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Michael Truog]

The modularity/usability issues mainly seem to be related to the fact that I see it as overkill for most projects that I would be interested in. So, this is a subjective judgment, where I don't want to get locked into an obscure templating format, etc. The activity issue impacts decisions about newer features. When I have looked at the yaws code in the past, it looks like legacy code, where there are modifications for various features scattered in various ways. I can understand how its age with all the various testing should make it the most stable full-featured choice. However, for new integration work it becomes overkill due to its complexity and the lack of modularity within the code-base. I say this, because if yaws was written in a modular way, it seems like you could easily pull a few modules to replace misultin functionality with something that has more testing. If that was possible, perhaps it would even perform better than misultin and cowboy, but it seems like
doing that has not been possible, nor would it be possible in the future (due to the legacy nature of yaws). Inets usually seems to go unmentioned in these discussions and the benchmarks, but it would be interesting to see how it might compare to yaws and the other choices.

[Edmond Begumisa]

On Fri, 17 Feb 2012 17:18:54 +1100, Michael Truog <mjt...@gmail.com>
wrote:

> The modularity/usability issues mainly seem to be related to the fact

> that I see it as overkill for most projects that I would be interested
> in. So, this is a subjective judgment, where I don't want to get locked
> into an obscure templating format, etc.

I see.

I was just pointing out that I never seen comparisons made between Apache
vs libmicrohttpd vs Django, nor have I heard of someone having a "dilemma"
choosing between these three completely different (but related)
technologies focused on solving different problems. Yet curiously, this
sort of comparision frequently occurs on this list in dicussions relating
to Erlang and the web.

> The activity issue impacts decisions about newer features. When I have
> looked at the yaws code in the past, it looks like legacy code, where
> there are modifications for various features scattered in various ways.
> I can understand how its age with all the various testing should make it
> the most stable full-featured choice. However, for new integration work
> it becomes overkill due to its complexity and the lack of modularity
> within the code-base.

Fair enough. I haven't personally tried to add features to yaws so I can't
comment.

> I say this, because if yaws was written in a modular way, it seems like
> you could easily pull a few modules to replace misultin functionality
> with something that has more testing. If that was possible, perhaps it
> would even perform better than misultin and cowboy, but it seems like
> doing that has not been possible, nor would it be possible in the future
> (due to the legacy nature of yaws).

Another way to look at it: If misultin and cowboy were available at the
time, maybe Claes Wikstrom would have used one of them to write yaws,
which according to one of his interviews[1], was written as a result of
his understandable frustration with the popular Apache-PHP combination,
rather than as extensible lightweigth web library for Erlang.

> Inets usually seems to go unmentioned in these discussions and the
> benchmarks, but it would be interesting to see how it might compare to
> yaws and the other choices.
>

In my view, any credible benchmark mentioning yaws must talk about content
and caching:

* Delivery of un-cached static content
* Delivery of un-cached dynamic content
* Delivery of cached content
* Delivery of streamed content
* Delivery when caches are full
* Delivery when complex session data is involved

If these things aren't being measured, it's likely that an apples and
oranges comparision is being made, because these are the things that
matter when I choose to use yaws (and I guess when most people choose
yaws.)

[1]
http://bsdtalk.blogspot.com.au/2006/08/bsdtalk062-interview-with-yaws.html

- Edmond -

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Ulf Wiger]

On 17 Feb 2012, at 03:09, Steve Davis wrote:

I'm a bit confused by this whole thread...

I'm agreeing with Jesse that since Misultin is open source, it's not
really in your control to "stop development" if the interest is there
elsewhere to push it on?

I read Roberto's announcement as saying that *he* would stop development on Misultin. I think it's admirable that he clearly declares his intentions.

On occasion, someone else might pick up another component and move forward with it - like Joseph Norton has with UBF. Either way, it's good for users to know that the previous maintainer has moved on to other things, and why.

BR,

Ulf

[Ulf Wiger]

On 17 Feb 2012, at 00:06, Michael Truog wrote:

With yaws the concern seems to be more about the code being regarded as legacy, not actively developed, and not modular (and whatever other reasons that seemed to make mochiweb
appear necessary).

I think this is no longer true. My impression is that yaws development has picked up again, Looking at the change log for the releases in the past year or two [1], it is obvious that it is being actively maintained. This is also apparent from the github stats [2]. And yaws now comes with generic support for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even WebSockets. One of the few things I miss is WebMachine support. :)

[1] http://yaws.hyber.org/

[2] https://github.com/klacke/yaws/contributors

BR,

Ulf W

[Joe Armstrong]

Thanks for all your hard work Roberto - I've been a fan
of Misultin for a while now. I always choose the code
with the best documentation since I don't care about efficiency.

So thanks once again for your efforts.

BWT I posted

https://github.com/joearms/adapter_pattern

today - this provides a 100% identical interface to
mochiweb, misultin and cowboy (and a scripting language EHE) which
should remove some of the pain of moving from
misultin to "something else".

Cheers

/Joe

[Steve Davis]

On 2/17/2012 2:33 AM, Ulf Wiger wrote:
> I read Roberto's announcement as saying that *he* would stop development
> on Misultin. I think it's admirable that he clearly declares his intentions.

OK, fair enough -- I guess I was diverted by the title of the thread
"Misultin EOL" which I read as the end of life for Misultin as an
application library.

[Steve Vinoski]

Very true, Ulf. And we'll get you that webmachine support soon.

And Michael, another way anyone can see how active yaws development is
is to simply look at the commits:

https://github.com/klacke/yaws/commits/master

This approach would seem vastly preferable to spreading inaccurate and
irresponsible rumors on this mailing list about yaws not being
actively developed. I've been using yaws for the past 5 years, much of
it in a production embedded system, and it's been actively developed
for all 5 of those years. Yaws is now in its 11th year of active
development.

Regarding yaws modularity, I keep hearing this rumor that it lacks in
that regard, yet nobody has yet pointed out any specifics. If someone
were to point out things they think are too intertwined, then Klacke,
Christopher Faulet, or I -- those with commit rights to the yaws repo
-- could at least consider fixing them, as could anyone else with an
interest in providing a patch. But in the absence of anything
concrete, it's hard to take action.

Note that the production embedded system I mentioned earlier doesn't
use SOAP or haxe or websockets or numerous other yaws features, and in
fact doesn't even include them, plus it runs embedded within a larger
application, not as a stand-alone server. If it truly lacked
modularity, or if it weren't usable in a library-like fashion, none of
that would be possible.

Earlier in this thread we have this gem from Loïc:

> I'm sad to see Misultin go, this was in my opinion the only other project that had enough
> momentum to introduce innovation in Erlang web servers.

Wow. At best, this is simply ignorant on several fronts. At worst,
it's insulting to Klacke, Bob Ippolito, me and others who've put a lot
of work into their Erlang web servers and continue to do so. Hell,
Erlang wouldn't be where it is today without all the features Klacke
put into it, and I doubt Erlang web systems would be as far along as
they are now without Klacke's and Bob's continued contributions and
deployments into real products in years where most of us hadn't even
started using Erlang yet. Part of the reason Roberto has taken this
new action regarding misultin is that he wants the Erlang web
community to become more cohesive, reusing each other's work instead
of competing with each other, but irresponsible statements like this
one from Loïc don't help Roberto's cause at all. If we truly want the
Erlang web dev community to become less fractured so it can grow,
taking cheap shots at each other won't get us there.

Yaws exists and continues to exist because people continue to use it
in real-life production systems. Klacke, Christopher, and I all have
day jobs, so whatever time we put into yaws is based on what users are
asking for. What makes it real interesting and fun is to fit new
features like websockets into a system without it being an ugly hack
and without breaking everything else that's already there, and we
intend to continue to do exactly that.

Perhaps worst of all about parts of this thread, though, is that from
what I've seen over the past few years, those spreading these
unfounded rumors about yaws being old and creaky and slow and legacy
and not actively developed and not usable for their projects never
once contacted Klacke or me or the erlyaws mailing list about
questions or issues with the system. They've never attempted to
contribute to the system with features or patches. I therefore suspect
that they just listened to the same recurring unfounded gossip and
made up their mind that way. Unfortunate, if true. But surely it's not
asking too much to request that, going forward, people at least do
their homework, try things out, and maybe ask some questions before
stating "facts" that simply aren't true about yaws, or mochiweb, or
any other such systems?

--steve

[Loïc Hoguin]

On 02/17/2012 04:06 PM, Steve Vinoski wrote:
> Earlier in this thread we have this gem from Loïc:
>> I'm sad to see Misultin go, this was in my opinion the only other project that had enough
>> momentum to introduce innovation in Erlang web servers.

I'm sorry if you misunderstood this but you also provide the reason why
I have that opinion.

> Yaws exists and continues to exist because people continue to use it
> in real-life production systems. Klacke, Christopher, and I all have
> day jobs, so whatever time we put into yaws is based on what users are
> asking for.

Misultin and Cowboy are still at a point in the projects' life where
features continue being added or improved before users request them, not
the other way around. They can also afford to break the API a little if
a better solution exists, since both of them aren't considered stable at
this point.

That's all I meant.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines

[Garrett Smith]

On Thu, Feb 16, 2012 at 3:17 PM, Steve Vinoski <vin...@ieee.org> wrote:
> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjt...@gmail.com> wrote:
>> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?
>
> I'm not interested in flames either, but I am interested in facts.
> Please back up your assertion by posting your meaningful benchmarks
> that prove that Yaws is lacking in performance.

FWIW, I spent some time looking at HTTP servers a couple years ago in
developing Landshark [1], which uses Mochiweb.

I found that *any* Erlang HTTP server, and certainly YAWs, was
decisively both faster and more resilient to faults than the other
language environment options I looked at, which the exception of
mod_php, which also fared very well. [2]

That said, I place little credence in these sorts of benchmarks. They
provide data, but it's not always clear what you can correctly infer
from them. We do have a tendency to get our rulers out and start
measuring, even if what we're measuring is completely pointless [3].

I've also observed that developers will, for whatever reason, go to
incredible lengths to eek out even the slightest performance gains in
the web tier [4]. In every large scale Web application I've seen
though, the web tier is not a bottleneck -- it's the data tier that
gives us fits. Of course there are exceptions, but if performance is
that critical, there's C!

Garrett

[1] Landshark was my first Erlang project and is now totally defunct.
I'm a proponent of modlib - https://github.com/gar1t/modlib - which is
a supplement to Erlang's built in httpd server.

[2] https://github.com/gar1t/landshark/blob/master/doc/benchmarks.txt

[3] http://www.youtube.com/watch?v=xEJ1n13soWU

[4] http://www.youtube.com/watch?v=bzkRVzciAZg

[Edmond Begumisa]

Perhaps there is some lack of knowldege about the variety of things yaws
can do, and the ease with which it can do them. I have a *single*
permanent local yaws server on my dev laptop running several unrelated
apps, some of which have nothing to do with Erlang...

* One port serves a local copy of Erlang OTP documentation searchable via
the Xapian Omega CGI app (it took me 2 minutes to get that first working.)

* One port serves a local 200 GB copy of the Mozilla Developer Network
also searchable via Xapian Omega CGI.

* One port points to a directory that has ediable-links I use to point to
whatever Erlang web-apps I'm currently developing, which I usually deploy
to customers without trouble.

* Another port I use to serve XUL/JS files for Mozilla XULRunner
development.

How can anyone find yaws lacking?

- Edmond -

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Ulf Wiger]

On 17 Feb 2012, at 16:06, Steve Vinoski wrote:

On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger <u...@feuerlabs.com> wrote:

I think this is no longer true. My impression is that yaws development has

picked up again, Looking at the change log for the releases in the past year

or two [1], it is obvious that it is being actively maintained. This is also

apparent from the github stats [2]. And yaws now comes with generic support

for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even

WebSockets. One of the few things I miss is WebMachine support. :)

[1] http://yaws.hyber.org/

[2] https://github.com/klacke/yaws/contributors

Very true, Ulf. And we'll get you that webmachine support soon.

I knew you wouldn't be able to resist, Steve. :-)

FWIW, as has perhaps become evident, as we needed to pick a web server here at Feuerlabs, we had an open-ended discussion about the different alternatives, then decided to go with Yaws. First off, we will do our best to steer clear of tying ourselves to hard to any particular web server API, but I don't see that as a big problem. If we decide to change later on, it will be a small effort in our case.

We chose to start with yaws for exactly the reasons that have come up here. It's battle-proven, has remained stable over the years, and doesn't appear to have any big problems keeping up with the new kids on the block in terms of speed (at least within the margin of uncertainty given that Yaws really does strive hard to be fully compliant - something that means something to us, as it will be the point of interface for our external customers).

What impresses with Yaws is its long track record and feature list, and a quick look at the development activity made it obvious that it is being very well looked after.

That said, the energy around Cowboy is impressive too. Our choice was not a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have other fish to fry.

Steve, I'll be expecting a nice cold beer when we see each other at the SF Erlang Factory. ;-)

BR,

Ulf W

[Michael Truog]

I am glad yaws is now actively developed and I hope it will be used more in the future to help support your efforts. I am sorry for the misunderstanding.

- Michael

[Roberto Ostinelli]

On Fri, Feb 17, 2012 at 6:39 AM, Joe Armstrong <erl...@gmail.com> wrote:

Thanks for all your hard work Roberto - I've been a fan
of Misultin for a while now. I always choose the code
with the best documentation since I don't care about efficiency.

So thanks once again for your efforts.

and thank you for using misultin in the first place ^^_ websocket supports was first added thanks to a post you did on your blog regarding this, some time ago now.

r.

[eigenfunction]

Thank you steve for pointing that out.
I have found yaws to be one of the most complete real webservers on
the planet with
the potential to become the next apache. It s just sad that even in
the erlang community,
it is being mentioned as an afterthought. What i did find out when i
was looking for a nice way
to do web development in erlang was that, yaws was not only a
magnificent webserver, it is a web framework
as well. I stopped reading blogs about other erlang webservers after
that.

> erlang-questi...@erlang.orghttp://erlang.org/mailman/listinfo/erlang-questions

[Roberto Ostinelli]

On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger <u...@feuerlabs.com> wrote:

FWIW, as has perhaps become evident, as we needed to pick a web server here at Feuerlabs, we had an open-ended discussion about the different alternatives, then decided to go with Yaws. First off, we will do our best to steer clear of tying ourselves to hard to any particular web server API, but I don't see that as a big problem. If we decide to change later on, it will be a small effort in our case.

We chose to start with yaws for exactly the reasons that have come up here. It's battle-proven, has remained stable over the years, and doesn't appear to have any big problems keeping up with the new kids on the block in terms of speed (at least within the margin of uncertainty given that Yaws really does strive hard to be fully compliant - something that means something to us, as it will be the point of interface for our external customers).

What impresses with Yaws is its long track record and feature list, and a quick look at the development activity made it obvious that it is being very well looked after.

That said, the energy around Cowboy is impressive too. Our choice was not a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have other fish to fry.

this is exactly why i took misultin out of the picture.

we discussed about web servers, bob ippolito, steve vinoski and i some months ago at the riak 1.0 release party (there's proof! https://twitter.com/#!/ostinelli/status/134183807560593408/photo/1).

in my belief, we should be concentrating our efforts in a common 'low-level' library, on top of which we could build other services. in an extreme point of view, i even suggested that, should cowboy live up to the expectations, steve could consider it as being yaws engine, on top of which it could deliver all the amazing features yaws is capable of. obviously this ain't gonna happen anytime soon, yaws is way more mature/stable than cowboy.

my opinion is that there should be mainly two candidates:

. yaws

. cowboy

the different features / ease of maintenante / personal taste, etc. should be the discriminating factors.

i would _personally_ use (please, read the IMHO statement really loud in your head):

. yaws - for blown-up web applications with templates, etc;

. cowboy - for API / REST related stuff, or for building custom non-http protocols.

95% of my usage is in developing protocols and backend APIs, hence my added interest in cowboy.

cowboy adding webmachine's REST-like support was the decisive move that made me go for my decision in stopping public support for misultin (obviously, it is still used in production and probably will be for some time).

on a final note, i want to say that i'm really glad of the open source community reaction. it has acted very mature upon my decision, understanding the reasons and sharing the outcomes we all hope this may have.

now let's continue building amazing stuff ^^_

r.

[Andrew Berman]

I want to applaud you Roberto on stepping away from Misultin like this.  Far too often I see duplication of efforts of libraries simply because someone saw some functionality lacking in a library.  My biggest gripe these days is with JavaScript libraries.  It's almost like every day a new MV* library comes out which almost replicates something like Backbone or Knockout or whatever library.  My thought has always been that instead of creating a new one, how about helping out on an existing one to fill in the holes or to improve upon it.  It's simply mind-blowing how many JavaScript MV* libraries there are.  I, like you, switched to Cowboy based on the Webmachine-like adapter they just added.  I think it's MUCH better to have two solid libraries (e.g. yaws and cowboy) which are supported by the community-at-large rather than a fragmented set of tools which have little to no support and this is why I think you have done the right thing.  I want to thank you for Misultin, I sure learned a lot from the code.

--Andrew

[Tim Watson]

On 17 February 2012 02:09, Steve Davis <steven.cha...@gmail.com> wrote:

Hi Roberto,

I'm a bit confused by this whole thread...

I'm agreeing with Jesse that since Misultin is open source, it's not
really in your control to "stop development" if the interest is there
elsewhere to push it on?

I'm also agreeing with Steve that I've not seen any demonstration that
yaws is somehow "lacking",

For me, the last interesting benchmark that demonstrated anything
graspably real was "yaws vs apache".

A really interesting benchmark for today's "web server" would be, if
someone were willing to engage in a non-trivial effort, to make a
comparison of a full-fledged web application with full session
management and routing capabilities. Note that this would truly test
the appropriateness of the server's http APIs as well as the base
response. That kind of benchmark, for me, would seem more appropriate
and useful according to the epoch.

I've been suggesting this for some time now. I will make some time (somehow) to participate and I'm sure others will too.

[Tim Watson]

On 16 February 2012 22:05, Roberto Ostinelli <rob...@widetag.com> wrote:

On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm <gu...@sigma-star.com> wrote:

Not to state the obvious or anything, but Misultin is open source, so
someone could always step up to the plate and become the *official*
fork.

There will still be efforts to support Misultin: Chicago Boss uses it,
and barring some serious arguments against it, I'll still be adding
misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0
release.

So while it's unfortunate that Roberto is stepping away from Misultin
development, that doesn't mean it's necessarily dead - someone can
always take over.

-Jesse

hi jesse,

please don't suggest that. while i cannot avoid someone doing so, i could have kept maintaing misultin myself. as i said, it has been a hard decision.

my intent here is to avoid duplication of efforts, both for the contributors of the community (often reporting the same bugs in both repositories) and for the developers, which now have an hard time in deciding which way to go.

i just wanted to clear the way for a single webserver library, and cowboy seems to have much more developer time to actually maintaining it.

Personally I don't understand why having a single library is so great, although I respect your decision to do this and am very grateful for all the hard work you've put into misultin to date.

In *java-land* I like being able to choose between Tomcat, Jetty (for embedded stuff) and other commercial options too. I don't see why it's a bad thing at all, although I would *really* love it if Erlang had just one API for building standard web applications (a la servlets, but obviously more 'erlang-ish' in flavour) and then interesting stuff like Chicago Boss can be built on top of it.

Personally I'm not keen on simple bridge because I don't like parameterised modules, but in every other respect I think it's a laudable effort. If we could standardise on an API - and god knows, I *really like* the one in Cowboy - then I personally think that would provide more benefit than having 'just one implementation'. Personally I don't think having just one implementation is the answer though.

 

r.

[Tim Watson]

On 17 February 2012 15:06, Steve Vinoski <vin...@ieee.org> wrote:

Very true, Ulf. And we'll get you that webmachine support soon.

 

I'll jump on YAWS in a second, once that webmachine support is available. YAWS maturity is a big selling point for me. Most of the time, I don't want to think about generating HTML. Most of the web applications we've built at work are RESTful web services, which serve up either XML, JSON or both. None of them actually serve web pages - we have static HTML/Javascript content served up by nginx in front of Mochiweb/Misultin that makes ajax calls to the back end. Another feature that we rely on is streaming (or chunking) the response back to the client, which YAWS appears to do very nicely.  

I'd still really like it if all these applications had a consistent API though. One thing I really appreciate about YAWS and Cowboy is that they both avoid parameterised modules. Not that I care one way or the other about whether parameterised modules are good or bad TBH, just that they're not officially supported and that puts me off. 

[Andrew Berman]

Tim,

I think a comparison between the Java app servers is not really accurate.  The reason I say that is that most have commercial support.  Tomcat might be the only one without commercial support, but it's the reference implementation and has plenty of books about it.  As far as I know with all the other popular ones there is some company who's willing to support it.  I think that's a big difference here between comparing Java app servers and Erlang servers.  Misultin is completely open-source with one man supporting it and no commercial support.  I'd much rather see fewer servers with better support and possibly commercial support than many with little support.

I do agree completely that Erlang needs a consistent servlet-like API.  It would certainly help a lot.

I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not.  If they don't, just get rid of it.  What's the point of having something in a language if it's not going to be supported (but that's a different topic)?

--Andrew

[Jesse Gumm]

I agree with you about the parameterised modules.  I'm not a big fan
of them either (though seeing how it works, I do understand why Rusty
went that route), and the deprecation of the tuple modules had me
scared for a moment. After that happened, I've been starting to think
about a roadmap away from the parameterised modules with
simple_bridge.

-Jesse

> Personally I'm not keen on simple bridge because I don't like parameterised
> modules, but in every other respect I think it's a laudable effort.

> ...

> Not that I care one way or the other about whether parameterised modules are
> good or bad TBH, just that they're not officially supported and that puts me off.

>
>>
>>

>> r.
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-q...@erlang.org
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[Tim Watson]

On 17 February 2012 22:42, Andrew Berman <rex...@gmail.com> wrote:

Tim,

I think a comparison between the Java app servers is not really accurate.  The reason I say that is that most have commercial support.  Tomcat might be the only one without commercial support, but it's the reference implementation and has plenty of books about it.  As far as I know with all the other popular ones there is some company who's willing to support it.  I think that's a big difference here between comparing Java app servers and Erlang servers.  Misultin is completely open-source with one man supporting it and no commercial support.  I'd much rather see fewer servers with better support and possibly commercial support than many with little support.

Yes ok, you make a very good point there. I hadn't thought about that, and on a few minutes reflection, I think you're quite right. 

 

I do agree completely that Erlang needs a consistent servlet-like API.  It would certainly help a lot.

Yes. There database libraries need this too. Java might be pants, but there are a few good things we can learn from it, and consistent APIs are one of them.

 

I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not.  If they don't, just get rid of it.  What's the point of having something in a language if it's not going to be supported (but that's a different topic)?

Yes indeed, same here. Personally I actually find them rather unintuitive, but I'd use them more readily in other people's libraries if they were properly supported. We've actually got Misultin running in production and it's been great, so it's not that I'm completely allergic to parameterised modules, just that I would prefer not to have them in an API.

[Tim Watson]

On 17 February 2012 22:49, Jesse Gumm <gu...@sigma-star.com> wrote:

I agree with you about the parameterised modules.  I'm not a big fan
of them either (though seeing how it works, I do understand why Rusty
went that route), and the deprecation of the tuple modules had me
scared for a moment. After that happened, I've been starting to think
about a roadmap away from the parameterised modules with
simple_bridge.
 

I think that's a good idea.

I would also like to respectfully suggest that api implementations might be distributed separately from the api itself, so that I can choose to get simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other stuff. Just a suggestion you may wish to consider.

Cheers,

Tim

[Andrew Berman]

I think a lot of issues with APIs would be solved if we had something analogous to Java interfaces in Erlang.  Behaviors just don't cut it.  I want something that is a replica of interfaces.  Then all the Erlang guys have to do is create the interface and then people can create whatever implementations they want and I never have to worry about changing my code!

[Yurii Rashkovskii]

I think this new -callback stuff is more apt to solving the problem of interfaces.

[Yurii Rashkovskii]

Andrew,

>I think a lot of issues with APIs would be solved if we had something analogous to Java interfaces in Erlang.  Behaviors just don't cut it.  I want something that is a replica of interfaces.  Then all the Erlang guys have to do is create the interface and then people can create whatever implementations they want and I never have to worry about changing my code!

[Tim Watson]

If I've understood this properly, then the -callback thing will provide a compile time check for the implementors of the callback interface into the custom behaviour, but gives nothing to the (external) client. Now what Andrew and I are looking for in practise, is something roughly like

DbHandle = dbms:bind(pgsql, DriverConfig),

DbConnection = dbms:connect(DbHandle, dbms:connection_info(Catalog, Schema, AuthMode))

Results = dbms:execute_query(DbConnection, "select * from foo"),

dbms_result_set:foldl(Results, [], fun collect_foobar/2) 

So I can change 'pgsql' to 'pgsql2' or 'oracle-oci' or 'mysql' or whatever, I can call connect/2 with *any* valid `-opaque db_handle() :: ...' data, call execute_query/2 with *any* valid `-opaque db_connection() :: ...' and I can rely on all implementations returning a structure that I can pass to dbms_result_set foreach/map/foldl and it will 'just work' even if the result set has to have a 'pointer' to those functions or (less tidily) I have to pass the DbHandle to those functions.

Here I can clearly rely on only the 'dbms' API and the people who have to do the heavy lifting are the implementors or 'pgsql' and similar libraries, who have to make sure that their libraries conform to the -callback interface(s) defined by the dbms application. I think though, that there is a question of state that makes this a bit awkward in practise (because even if there are no processes behind the custom behaviour, you still have to maintain the binding to the implementation module(s) somewhere) and also it makes implementing the API more complicated than simply saying 'define these callback functions'. I think this is why so many API efforts (such as simple_bridge) seem to end up using parameterised modules.

A classic example of this is the recent conversation about unifying the dict APIs, but you could apply that to lots of other situations. How can I do that using the -callback approach?

D = dict_api:new(dict | orddict | ....)

%% add some stuff

dict_api:find(key1, D2)

So at a minimum, the implementor of dict_api needs to return (a) the module that implements its -callback interface and (b) whatever state/data that is required in order to fulfil any subsequent call. Now if there was a bit of sugar that allowed me to do this dbms:bind and dict_api:new stuff so that I only need to 

1. define the -callback interface somewhere as the API

2. have a way to get an implementation of the callback interface for any module that provides that -behaviour

then things would be good right!? But I want this to work without breaking hot loading/upgrades, so I'm not convinced that it's so easy to do when you're effectively spending a lot of time passing around the module name(s) in a bunch of variables or embedded in some records or whatever. What we're looking for is a way to say

%% bind the -callback source to an implementation

-bind(api_module, implementation_module).

do_something() ->

    api_module:do_something(....)

And make sure that when an upgrade takes place, that what's *really* happening is that the call is being made to 'implementation_module' and any change to 'implementation_module' will trigger a proper code change. I suppose this might be achievable with a parse_transform (that translates from mod_api to the other) but that feels a bit messy and it would be nice for the compiler to check the client code for consistency with the exported -callback API too.

That's probably a terrible approach, but I hope you get the gist of what we're thinking about.

  

 

[Joe Armstrong]

This is *exactly* what I posted yesterday :-)

See https://github.com/joearms/adapter_pattern

I have made three independent adapters (call them bridges if you like)
to misultin, mochiweb and cowboy.

With this you can change the entire backend by changing
*one* module name in one place in the code.

They use parameterised modules to hide all the messy details. Probably
isolation via an addition process would be better - I don't know, but
I suspect this to be the case.

/Joe

>
> Cheers,
>
> Tim

[Joe Armstrong]

On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson <watson....@gmail.com> wrote:
> On 17 February 2012 02:09, Steve Davis <steven.cha...@gmail.com>
> wrote:
>>
>> Hi Roberto,
>>
>> I'm a bit confused by this whole thread...
>>
>> I'm agreeing with Jesse that since Misultin is open source, it's not
>> really in your control to "stop development" if the interest is there
>> elsewhere to push it on?
>>
>> I'm also agreeing with Steve that I've not seen any demonstration that
>> yaws is somehow "lacking",
>>
>> For me, the last interesting benchmark that demonstrated anything
>> graspably real was "yaws vs apache".
>>
>> A really interesting benchmark for today's "web server" would be, if
>> someone were willing to engage in a non-trivial effort, to make a
>> comparison of a full-fledged web application with full session
>> management and routing capabilities. Note that this would truly test
>> the appropriateness of the server's http APIs as well as the base
>> response. That kind of benchmark, for me, would seem more appropriate
>> and useful according to the epoch.
>
>
> I've been suggesting this for some time now. I will make some time (somehow)
> to participate and I'm sure others will too.

Yes ^ 100

My *minimal* application does this for *every* GET request

1) Is there a cookie?
2) If no cookie redirect to a set-cookie page
3) if there is a cookie lookup value in database
4) if no value in DB redirect to warning page
5) if there is a value check if user is authenticated
6) if not authenticated redirect to login page
7) if authenticated lookup same basic data about user
in DB
8) send the result

I suspect that impedance mismatches between the DB and
web server are the main sources of inefficiency

The *interesting* benchmark is (say) the number of
page-views in a forum/second or the number of searches/second in a forum.

We need to implement something like PHPBB and benchmark the number of
page-views/second
(Actually doing so would involve even more work before a page gets
sent - is the IP blacklisted? - has the user
posted more than N requests in the last T seconds -
is the user a spammer...)

One thing that hinders this is the lack of a common language
to implement the web-part in. I have made a little language
EHE for this - which included in my adapter pattern - EHE is
easy to embed in *any* erlang web server - I have done so
for misultin, cowboy and mochiweb see

https://github.com/joearms/adapter_pattern

The database for something like a web forum needs
investigation:

I want a data base with the following characteristics

- persistent
- Key-Value
- fast lookups
- slow writes
- full-text indexing of certain fields of certain key-types

In a forum type application the read-write ratio is heavily
skewed in favor of reads - ie lots of reads very few writes.

I am making a systems where all keys-values are stored in
an ets table.

Reads go to the ets table, writes go to the ets table and are trailed
on disk. I guess I'd also like large values on disk
small values in the ets table. Oh and I'd also like full-text indexing
on tuple fields. ie if I say

store({post,12456},#item{user="joe", text="......"})

Id like to automatically index the text field of the record.

No erlang database I know of fits the bill - I don't want
an interface to mySQL or whatever since I suspect the impedance
mismatch between Erlang and the external
database would be terrible.

Summary:

In addition to a fast web-server we need

- a fast persistent DB suitable for web applications
- zero impedance mismatch between the DB and the web server
- a language for the application (like PHP) (you'll find my
EHE at https://github.com/joearms/adapter_pattern)
- authentication

All these bits have to fit together with bridges (adapters) so
we can change the database/server/authentication without
having to rewrite the entire application.

Do this and *then* benchmark against PHPBB (or something)

Cheers

/Joe

[Ulf Wiger]

On 17 Feb 2012, at 23:42, Andrew Berman wrote:

I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not.  If they don't, just get rid of it.  What's the point of having something in a language if it's not going to be supported (but that's a different topic)?

I agree that if something is added as an experimental feature, it should either be graduated or removed as soon as possible, not stay experimental indefinitely.

BR,

Ulf W

[José Valim]

I'd be keen on simple bridge if the Erlang guys would just come out and say if they support parameterized modules or not.  If they don't, just get rid of it.  What's the point of having something in a language if it's not going to be supported (but that's a different topic)?

I agree that if something is added as an experimental feature, it should either be graduated or removed as soon as possible, not stay experimental indefinitely.

I don't use parameterized modules at all but it would be a pity to see { module, args }:function() go.

[Joe Armstrong]

It will stay - and be documented to make it official

/Joe

[Benoit Chesneau]

On Sat, Feb 18, 2012 at 12:05 AM, Andrew Berman <rex...@gmail.com> wrote:
> I think a lot of issues with APIs would be solved if we had something
> analogous to Java interfaces in Erlang.  Behaviors just don't cut it.  I
> want something that is a replica of interfaces.  Then all the Erlang guys
> have to do is create the interface and then people can create whatever
> implementations they want and I never have to worry about changing my code!
>

In python world we have WSGI that define a common spec to interface
Python application with the web. Defining how server should handle
requests to and return response from applications. Also defining how
the requests/responses should be formatted for the apps.

There are many servers and many libs/frameworks handling the spec.
Only the code quality, the technical differences and features distinct
them. I guess somethng like that could be defined in Erlang with a
lib reference to test the validaty and validate servers and libs
behaviour (just like wsgiref in Python). Same exist with Rack in ruby
world and probably in other language.

Maybe that something that could be done. It would at least simplify a
lot the work of apps developers.

- benoît

[Gordon Guthrie]

> . yaws - for blown-up web applications with templates, etc;
> . cowboy - for API / REST related stuff, or for building custom non-http
> protocols.

On a similar note it would be good to get a consistent authentication
mechanism for using API's so that people didn't need to first build
their own mechanism and THEN painfully build a community of developers
who have built and contributed libraries conformant to it in other
languages.

I made a start by building an AWS-clone private, public keypair
authentication library which I committed upstream (to us) to mochiweb:
https://github.com/mochi/mochiweb/blob/master/examples/hmac_api/README

The aim is to make it as easy as possible to release an API that
extends out to the libraries that API consumers need to build their
applications in their own languagues.

I know Yaws a bit, but I am not that familiar with misultin and
cowboy. Is anyone else working on libraries like this that I should
co-ordinate with?

Gordon

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Gordon Guthrie
CEO hypernumbers

http://hypernumbers.com
t: hypernumbers
+44 7776 251669

[José Valim]

There are many servers and many libs/frameworks handling the spec.
Only the code quality, the technical differences and features distinct
them.  I guess somethng like that could be defined in Erlang with a
lib reference to test the validaty and validate servers and libs
behaviour (just like wsgiref in Python). Same exist with Rack in ruby
world and probably in other language.

I agree that a common interface is desired but we should steer far away from Rack and WSGI. Rack in particular was designed with the concept of endpoint that is the entity responsible for calculating the response and send it back after the response is generated. This means that async and streaming the response as you get it are very hard to achieve because the whole ecosystem and the specs were not designed to handle such scenarios.

Something that gets this right though is servlet API from Java with the concept of generators, filters and etc. Streaming works fine as you can, at any point, push data into the socket and filters/generators are wrapped by this API.

Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a part of me dies because the ability of streaming and asynchronously pushing stuff down the socket is one of the best features you would have in such frameworks.

PS: I am one of the core members of Rails by far the biggest framework that relies on Rack. We tried to add streaming on Rails 3.1 which made very clear all the shortcomings of the Rack API. We will eventually work on a Rack 2.0 that is more inspired by the Servlet API.

[Benoit Chesneau]

well at least in wsgi, nothing stop you to stream your content. Or
even use sendfile. But right that's something a spec should take in
consideration. In gunicorn for example I added the socket to the WSGI
environ.

[José Valim]

Yeah, you can put it in the environment but your whole middleware stack ends up clueless of what is happening. Same for streaming. Everything is created based on the wrong expectations. Async should be a requirement, not a nice to have. I hope to have more news published about this soon.

[Robert Virding]

I have seen behaviours used in this way. All the behaviour contained was the behaviour_info/1 function which just returned the functions' name/arity. It was created for just this purpose. But it is not how behaviours were intended.

Robert

---

[Tim Watson]

On 18 February 2012 11:30, José Valim <jose....@gmail.com> wrote:
>
> Something that gets this right though is servlet API from Java with the
> concept of generators, filters and etc. Streaming works fine as you can, at
> any point, push data into the socket and filters/generators are wrapped by
> this API.
>

+1. The Java Servlet API is excellent. Filter chains provide a simple
and consistent approach to request wrapping, and Servlets provide just
the right low level API for interacting with the request and/or
response, allowing you to get to the socket API underneath if you need
to. Good frameworks can be built on top of this easily.

I also like that you configure filters/servlets using exactly the same
XML configuration regardless of the web server you're running in.
Obviously I'd prefer it if it wasn't XML, but the consistency is the
thing. YAWS uses config files in this way (e.g., for setting up
appmods) and I wish all the web server frameworks did the same, or at
least the whatever common API was available would support the notion.

> Every time I see a Erlang or a Node.js framework based on top of Rack/WSGI a
> part of me dies because the ability of streaming and asynchronously pushing
> stuff down the socket is one of the best features you would have in such
> frameworks.
>
> PS: I am one of the core members of Rails by far the biggest framework that
> relies on Rack. We tried to add streaming on Rails 3.1 which made very clear
> all the shortcomings of the Rack API. We will eventually work on a Rack 2.0
> that is more inspired by the Servlet API.
>

JDBC and the Servlet API are both exemplary parts of the Java world.
In fairness to the .NET crowd, the ADO.NET and IIS centric web APIs
(HttpHandler and HttpModule) do it almost exactly the same way.

[Tim Watson]

Hi Joe,

I don't think you actually *need* a single scripting language to rule
them all - nowhere else is this the case. Even in PHP there are
templating and MVC frameworks, because fundamentally any large code
base begins to fray at the seams in the face of 'scriptlet' code
because it is

(a) hard to isolate and therefore
(b) hard to unit test
(c) makes it 'easy' to do the wrong thing and mingle view generation
and business logic, violating separation of concerns

Personally I avoid things like this (PHP, JSP, ASP.NET, etc) like the
plague, opting for templating tools like ErlyDTL or - more often than
not - generating JSON/XML directly from the data model and
streaming/serialising this back to the client.

Other than that, I think a consistent interface between the different
web servers is a bloody awesome step in the right direction. One thing
that simple_bridge does well, in its philosophy at least, is to
delegate to the underlying framework/server as much as possible, for
things like identifying the mime type.

Also I don't think that the implementation adapter should make choices
about, for example, the JSON library used to do the
serialisation/de-serialisation as in
https://github.com/joearms/adapter_pattern/blob/master/mochiweb_adapter.erl#L48.
I want to make my own choices when I'm building a web application,
which include

1. what libraries I use to serialise/de-serialise data
2. what scripting and/or templating libraries I wish to use to
generate content (if this approach is in play)
3. what response codes I want to send to the client

So I fundamentally like where you're going with this, but it's a bit
too high a level of abstraction for a 'generic web server api' and is
making too many choices about these things (above). You need to offer
lower level APIs that bridge the different web servers, as
simple_bridge does. And on that note, if parameterised modules are
going to be official and 'ok' soon, then simple_bridge is actually a
long way ahead already, so maybe it's worth spending some time looking
at it too.

[Joe Armstrong]

I quite agree - this code was just a proof-of-concept not
frozen in stone.

As I see things there are two layers:

*inside* EHE I'd write code like this:

<?e Value = SYS:get_key(Key),,, ?>

SYS:get_key(Val) would have a well defined type that never changes.

*outside* EHE I would define the semantics of get_key
so I could say If I wanted a memory resident db, persistent,
replicated, authenticated and so on.

> which include
>
> 1. what libraries I use to serialise/de-serialise data
> 2. what scripting and/or templating libraries I wish to use to
> generate content (if this approach is in play)
> 3. what response codes I want to send to the client
>
> So I fundamentally like where you're going with this, but it's a bit
> too high a level of abstraction for a 'generic web server api' and is
> making too many choices about these things (above). You need to offer
> lower level APIs that bridge the different web servers, as
> simple_bridge does. And on that note, if parameterised modules are
> going to be official and 'ok' soon, then simple_bridge is actually a
> long way ahead already, so maybe it's worth spending some time looking
> at it too.

I agree

/Joe

[Jesse Gumm]

Well that is good news to hear that param modules are here to say.

--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866

www.sigma-star.com
@jessegumm

[Joe Armstrong]

On Sat, Feb 18, 2012 at 5:16 PM, Jesse Gumm <gu...@sigma-star.com> wrote:
> Well that is good news to hear that param modules are here to say.

Well actually it's the abuse of PMs that will stay.

That {Mod,a,b,c}:foo(x,y) means foo(x,y,{Mod,a,b,c})
is an accidental side effect of the way parameterised modules
were implemented.

The "official way of creating a PM" is with Mod:new(...)
and NOT PM = {Mod,a,b,c}. Somebody (I don't know who)
discovered how to build a PM *without* calling Mod:new.

I discovered this when reading the misultin code since this
has never been documented. I fell mentally off my chair - I had no
idea this was possible. I think (I speculate here) that
misultin got the idea from mochiweb, but how mochiweb got the idea I know not.

It's actually a very nice mechanism - the MFA and fun alternatives are
a few characters more and less pretty
so it will stay.

/Joe

[Bob Ippolito]

On Sat, Feb 18, 2012 at 8:58 AM, Joe Armstrong <erl...@gmail.com> wrote:

On Sat, Feb 18, 2012 at 5:16 PM, Jesse Gumm <gu...@sigma-star.com> wrote:
> Well that is good news to hear that param modules are here to say.

Well actually it's the abuse of PMs that will stay.

That {Mod,a,b,c}:foo(x,y) means foo(x,y,{Mod,a,b,c})
is an accidental side effect of the way parameterised modules
were implemented.

The "official way of creating a PM" is with Mod:new(...)
and NOT PM = {Mod,a,b,c}. Somebody (I don't know who)
discovered how to build a PM *without* calling Mod:new.

I discovered this when reading the misultin code since this
has never been documented. I fell mentally off my chair - I had no
idea this was possible. I think (I speculate here) that
misultin got the idea from mochiweb, but how mochiweb got the idea I know not.

It's actually a very nice mechanism - the MFA and fun alternatives are
a few characters more and less pretty
so it will stay.

I think that the paper introducing PMs mentioned it, but it's hard not to see what the representation of a PM looks like at the prompt.

-bob

 

[Steve Vinoski]

On Fri, Feb 17, 2012 at 10:13 AM, Loïc Hoguin <es...@ninenines.eu> wrote:
> On 02/17/2012 04:06 PM, Steve Vinoski wrote:
>>
>> Earlier in this thread we have this gem from Loďc:
>>
>>> I'm sad to see Misultin go, this was in my opinion the only other project
>>> that had enough
>>> momentum to introduce innovation in Erlang web servers.
>
>
> I'm sorry if you misunderstood this but you also provide the reason why I
> have that opinion.
>
>
>> Yaws exists and continues to exist because people continue to use it
>> in real-life production systems. Klacke, Christopher, and I all have
>> day jobs, so whatever time we put into yaws is based on what users are
>> asking for.
>
>
> Misultin and Cowboy are still at a point in the projects' life where
> features continue being added or improved before users request them, not the
> other way around. They can also afford to break the API a little if a better
> solution exists, since both of them aren't considered stable at this point.
>
> That's all I meant.

Sorry but a) I don't see how you expect anyone to be able to derive
this interpretation from what you originally said, and b) this still
has nothing to do with innovation. Do you equate innovation with
greenfield development? You have to break APIs just to innovate? If so
that's awfully misguided.

I suggest studying the work of Clayton Christensen and his Harvard
Business school colleagues, as well as others such as Geoffrey Moore
and Steve Denning if you want to know what innovation actually is.
When it comes to innovation, Scott Berkun, author of "The Myths of
Innovation", once offered this advice:

http://www.scottberkun.com/blog/2008/stop-saying-innovation-heres-why/

Fact is, plenty of innovation has occurred in Yaws over the past few
years. When I added process-based streaming, for example, it enabled
long-polling apps and served as a basis for websocket support. It also
allowed me (in my day job at the time) to integrate Yaws with a
proprietary hardware TCP offload engine for video delivery, notably
without any special patches or changes to Yaws itself. Innovative? You
bet. Christopher Faulet added a number of small features over the past
year that are incredibly useful to anyone using Yaws in production.
Even just adding rebar support to Yaws led to several innovative
changes within rebar, making it cleaner in spots. I added support for
the relatively recent HTTP PATCH verb to Yaws even though nobody asked
for it, simply because it's in the spec. We even occasionally slightly
broke interfaces to make improvements. And we intend to continue to
innovate, through Yaws 2.0 and beyond.

As I said at Erlang Factory London 2011 and in my keynote at the
Erlang Workshop in Tokyo last September, my personal opinion is that
nobody should be writing new Erlang web servers. Every new
"lightweight" "library" web server eventually just gains weight to the
point where still another new project pops up to build something more
lightweight again. If you think something like this won't eventually
follow Cowboy, you're dreaming. But all these new web servers just
splinter the Erlang web development community IMO, and they result in
multiple efforts all having to implement the same support for the same
features, all in different non-reusable ways of course. If people want
to contribute they should instead be working either within existing
projects like Yaws, or perhaps better yet, within Erlang/OTP itself,
in both the Erlang code and the C code, to improve scaling and
performance at that level. Speed up the HTTP parsing within Erlang,
for example. Consider what the OTP team continues to do with multicore
performance, or what Scott Fritchie is doing with dtrace integration.
Doing stuff like that raises all ships -- all Erlang applications,
whether web-focused or not, benefit from such efforts.

--steve

[Steve Vinoski]

On Sat, Feb 18, 2012 at 6:18 AM, Benoit Chesneau <bche...@gmail.com> wrote:
> In python world we have WSGI that define a common spec to interface
> Python application with the web.

Something like this, EWGI, was built a few years ago, but never seemed
to go anywhere:

https://github.com/skarab/ewgi

--steve

[Garrett Smith]

On Sat, Feb 18, 2012 at 5:18 AM, Benoit Chesneau <bche...@gmail.com> wrote:
> On Sat, Feb 18, 2012 at 12:05 AM, Andrew Berman <rex...@gmail.com> wrote:
>> I think a lot of issues with APIs would be solved if we had something
>> analogous to Java interfaces in Erlang.  Behaviors just don't cut it.  I
>> want something that is a replica of interfaces.  Then all the Erlang guys
>> have to do is create the interface and then people can create whatever
>> implementations they want and I never have to worry about changing my code!
>>
> In python world we have WSGI that define a common spec to interface
> Python application with the web. Defining how server should handle
> requests to and return response from applications. Also defining how
> the requests/responses should be formatted for the apps.
>
> There are many servers and many libs/frameworks handling the spec.
> Only the code quality, the technical differences and features distinct
> them.  I guess somethng like that could be defined in Erlang with a
> lib reference to test the validaty and validate servers and libs
> behaviour (just like wsgiref in Python). Same exist with Rack in ruby
> world and probably in other language.
>
> Maybe that something that could be done. It would at least simplify a
> lot the work of apps developers.

WSGI is one of most successful middle layer implementation I've seen for HTTP.

By success, I mean the amount of code written around the spec. For the
most part, the entire Python web ecosystem, which is very rich, was
spawned by this spec.

http://www.python.org/dev/peps/pep-0444/

Some of what's been discussed in this thread (cookies, sessions, etc),
IMO, belongs at a higher level -- which is easily supported with a
good HTTP middleware layer.

FWIW, this exists today in the "mod" API for Erlang's own httpd
server. It's not a standard -- it's horrifyingly complicated -- but it
is representative of a WSGI style middle ware layer.

Garrett

[Garrett Smith]

On Sat, Feb 18, 2012 at 1:57 PM, Steve Vinoski <vin...@ieee.org> wrote:
> On Sat, Feb 18, 2012 at 6:18 AM, Benoit Chesneau <bche...@gmail.com> wrote:
>> In python world we have WSGI that define a common spec to interface
>> Python application with the web.
>
> Something like this, EWGI, was built a few years ago, but never seemed
> to go anywhere:
>
> https://github.com/skarab/ewgi

The problem with this project IMO is that it isn't a spec -- it's a
library. The success of WSGI is that it's a duck typed protocol -- you
don't need to download anyone's code to use it.

IIRC the prime directive of the WSGI design was to make it easy to
build clients, servers, and middleware. It worked out well I think.

Garrett

[Matti Oinas]

On 02/18/2012 09:55 PM, Steve Vinoski wrote:
> If people want
> to contribute they should instead be working either within existing
> projects like Yaws, or perhaps better yet, within Erlang/OTP itself,
> in both the Erlang code and the C code, to improve scaling and
> performance at that level. Speed up the HTTP parsing within Erlang,
> for example.

Steve has a really good point in that we should concentrate to improve
the existing and as few as possible different implementations and if
possible the one included in Erlang/OTP. Sometimes something new has to
be created to demonstrate the benefits and to make development go faster
but these new solutions shouldn't be recreated from the scratch just to
alter a minor part of existing solution. Instead improvements should be
made into existing code. If the old code isn't fast or good enough then
fix it instead of writing a new one. Open source can only help if we are
using existing solutions and trying to make them better instead of
trying to create a new and better one and leaving existing code unfixed.

I have written partially working web server and other common
applications/libraries myself but just for learning purposes and when I
have come to a conclusion that I have learned what I wanted then I just
move the codes to my backup HD and forgot they even exist. No one would
benefit anything from these codes because everything have been done
before and there exists good solutions to these problems allready.
Situation would have been different if I would have created a totally
different and good solution to existing problem. Then the code should be
published.

I'm not saying there should only exist one solution to every problem but
there shouldn't exist two or more allmost identical solutions to same
problem. First try to contribute to existing solution before creating a
new one.

Matti

[Loïc Hoguin]

I do use innovation in the disruptive sense, but it seems there is a
bigger issue at hand than my poor choice of words.

> Fact is, plenty of innovation has occurred in Yaws over the past few
> years. When I added process-based streaming, for example, it enabled
> long-polling apps and served as a basis for websocket support. It also
> allowed me (in my day job at the time) to integrate Yaws with a
> proprietary hardware TCP offload engine for video delivery, notably
> without any special patches or changes to Yaws itself. Innovative? You
> bet. Christopher Faulet added a number of small features over the past
> year that are incredibly useful to anyone using Yaws in production.
> Even just adding rebar support to Yaws led to several innovative
> changes within rebar, making it cleaner in spots. I added support for
> the relatively recent HTTP PATCH verb to Yaws even though nobody asked
> for it, simply because it's in the spec. We even occasionally slightly
> broke interfaces to make improvements. And we intend to continue to
> innovate, through Yaws 2.0 and beyond.

Please don't take this the wrong way, as once again I mean no harm.

I never heard about all the recent changes you mention. I don't follow
closely any of the server projects, due to lack of time, yet I heard
about all the developments happening in Misultin over the past year from
different sources (announcements, IRC, twitter mostly), up to the 0.9
version. For Yaws, I saw a release announcement a couple months ago, and
sometimes someone mentions it on IRC (always the same set of people
though). Evidently Yaws had websockets for a long time, yet people got
excited when I added them to my then 2 months old server as if it was
the only server that could do them (alongside Misultin, Websocket
support was added back-to-back in both projects IIRC).

This is bad because unless people talk about what your project can do
then people new to Erlang won't know it. I'm relatively new to Erlang
and when I looked for a web server initially I didn't hear about Yaws. I
heard about Webmachine (then found out it used Mochiweb internally, I
didn't hear much about Mochiweb specifically) and Misultin. I did take a
look at Yaws eventually, but I didn't hear much about it. There's an
increase in newcomers to Erlang, and if these newcomers don't hear more
often about what Yaws (or any other established project) can do and
where it's going, they won't consider it. Call it buzz or hype or what
you want, but that kind of communication is important if you want to
grab newcomers. All the veterans use Yaws, yet none of the newcomers, or
at least none of the ones I talk to, know about it. Something there is
wrong and should be fixed.

I hope I explained myself clearly this time and that it won't anger you.
If it does though I'll leave it as that. ;)

> As I said at Erlang Factory London 2011 and in my keynote at the
> Erlang Workshop in Tokyo last September, my personal opinion is that
> nobody should be writing new Erlang web servers. Every new
> "lightweight" "library" web server eventually just gains weight to the
> point where still another new project pops up to build something more
> lightweight again. If you think something like this won't eventually
> follow Cowboy, you're dreaming. But all these new web servers just
> splinter the Erlang web development community IMO, and they result in
> multiple efforts all having to implement the same support for the same
> features, all in different non-reusable ways of course. If people want
> to contribute they should instead be working either within existing
> projects like Yaws, or perhaps better yet, within Erlang/OTP itself,
> in both the Erlang code and the C code, to improve scaling and
> performance at that level. Speed up the HTTP parsing within Erlang,
> for example. Consider what the OTP team continues to do with multicore
> performance, or what Scott Fritchie is doing with dtrace integration.
> Doing stuff like that raises all ships -- all Erlang applications,
> whether web-focused or not, benefit from such efforts.

I for one hope that more servers appear and try out entirely new things.
I'm saddened to see Misultin go, and would feel the same if Mochiweb or
Yaws development stopped, because I think there is a bigger benefit in
having many projects instead of one. Each project has different goals
and this leads to quite different designs, that other projects can learn
from. I'm hopeful that one day someone will start yet another webserver,
even if just as an experiment, that can showcase a new way of improving
the existing software stacks.

And I'll add that if the improvements are big enough I'll gladly pull
out a new Cowboy version to add them to my project, even if it breaks
some compatibility, as long as it's in the project's scope and furthers
its goals.

When Cowboy initially appeared a lot of exchange happened between
Roberto and myself about ways to improve both projects, and that's
something I feel is very important. What's more important though is that
even if one project thinks one way of doing things is wrong, the other
can still do it. And maybe it was a good idea and it should stay, but
needed to be proven over time. I'm not sure how you can get this to
happen if you have a single project for the whole community. You can
fork, sure, but if changes are disruptive enough you just end up with
two projects again.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines

[Steve Vinoski]

On Sat, Feb 18, 2012 at 4:28 PM, Loïc Hoguin <es...@ninenines.eu> wrote:
> This is bad because unless people talk about what your project can do then
> people new to Erlang won't know it. I'm relatively new to Erlang and when I
> looked for a web server initially I didn't hear about Yaws.

I just googled:

erlang web server

and the Yaws home page is the very first link that popped up.

--steve

[Tristan Sloughter]

I was going to stay out of this but I must say that when I got started with Erlang webservers the way I understood it was mochiweb for using within your applications and yaws to serve static content. Whether or not that is/was accurate it seems to be what most heard.

Then I looked deeper at Yaws documentation and while it was clear it was able to do more, the documentation made it seem awkward compared to what I'd see from others. 

When I look to use webmachine, mochiweb, cowboy, misultin it seems clear using them in standard OTP apps and releases. Yaws, not so much.

Tristan

[Loïc Hoguin]

On 02/18/2012 11:05 PM, Steve Vinoski wrote:
> On Sat, Feb 18, 2012 at 4:28 PM, Loïc Hoguin<es...@ninenines.eu> wrote:
>> This is bad because unless people talk about what your project can do then
>> people new to Erlang won't know it. I'm relatively new to Erlang and when I
>> looked for a web server initially I didn't hear about Yaws.
>
> I just googled:
>
> erlang web server
>
> and the Yaws home page is the very first link that popped up.

That's not what people do when they want to know what they should use.
They ask others about it. Google is good to find something specific, not
to get an opinion.

--
Loïc Hoguin
Erlang Cowboy
Nine Nines

[Tim Watson]

On 18 February 2012 14:32, Joe Armstrong <erl...@gmail.com> wrote:
>
> I quite agree - this code was just a proof-of-concept not
> frozen in stone.
>

Sure, I understood that.

> As I see things there are two layers:
>
> *inside* EHE I'd write code like this:
>
>   <?e Value = SYS:get_key(Key),,, ?>
>
> SYS:get_key(Val) would have a well defined type that never changes.
>
> *outside* EHE I would define the semantics of get_key
> so I could say If I wanted a memory resident db, persistent,
> replicated, authenticated and so on.
>

Makes sense to me.

>
>
>> which include
>>
>> 1. what libraries I use to serialise/de-serialise data
>> 2. what scripting and/or templating libraries I wish to use to
>> generate content (if this approach is in play)
>> 3. what response codes I want to send to the client
>>
>> So I fundamentally like where you're going with this, but it's a bit
>> too high a level of abstraction for a 'generic web server api' and is
>> making too many choices about these things (above). You need to offer
>> lower level APIs that bridge the different web servers, as
>> simple_bridge does. And on that note, if parameterised modules are
>> going to be official and 'ok' soon, then simple_bridge is actually a
>> long way ahead already, so maybe it's worth spending some time looking
>> at it too.
>
> I agree
>

Cool - I think Ulf's point about parameterised modules was a good one.
They've been around for ages and should be 'finalised' now. I'm very
excited to see where this stuff goes.

Cheers,

Tim

[Ngoc Dao]

In my opinion Yaws is the best Erlang web server and many new comers
came because they saw this:
http://www.sics.se/~joe/apachevsyaws.html

One thing Yaws needs to improve is embedding.

[Tim Watson]

On 19 February 2012 00:12, Ngoc Dao <ngocda...@gmail.com> wrote:
> In my opinion Yaws is the best Erlang web server and many new comers
> came because they saw this:
> http://www.sics.se/~joe/apachevsyaws.html
>
> One thing Yaws needs to improve is embedding.
>
>

I'm pretty sure that since the Yaws build has been rebar-ized, it'll
not be too hard to figure out how to modify it to be (a) part of a
release instead of a stand alone deployable - if this is not already
the case as some on this thread seem to have suggested - and (b)
possible to make it easier to embed.

[Jesper Louis Andersen]

On 2/19/12 1:12 AM, Ngoc Dao wrote:
> In my opinion Yaws is the best Erlang web server and many new comers
> came because they saw this:
> http://www.sics.se/~joe/apachevsyaws.html
>
> One thing Yaws needs to improve is embedding.
>

Speaking from experience: Embedding yaws or cowboy is dead easy.

--
Jesper Louis Andersen
Erlang Solutions Ltd., Copenhagen, DK

[Ulf Wiger]

On 19 Feb 2012, at 01:24, Tim Watson wrote:

One thing Yaws needs to improve is embedding.

I'm pretty sure that since the Yaws build has been rebar-ized, it'll
not be too hard to figure out how to modify it to be (a) part of a
release instead of a stand alone deployable - if this is not already
the case as some on this thread seem to have suggested - and (b)
possible to make it easier to embed.

Well, I had my own facepalm moment when I first tried to get embedded yaws

working in a rebar-generated release, using what was pretty much exactly the 

json_rpc_example from the yaws docs.

The thing I didn't think of was that rebar releases use embedded code loading by

default, and I had omitted the 'compiler' app from the release. Because of this,

yaws couldn't compile the .yaws files.

A small gripe with yaws is that it gave me no clues about what was wrong.

Anyway, switching to appmods was very easy, and now, both methods work, as I

have the compiler app loaded.

BR,

Ulf W

[OvermindDL1]

On Sun, Feb 19, 2012 at 2:20 PM, Jesper Louis Andersen
<jesper.lou...@erlang-solutions.com> wrote:
> On 2/19/12 1:12 AM, Ngoc Dao wrote:
>>
>> In my opinion Yaws is the best Erlang web server and many new comers
>> came because they saw this:
>> http://www.sics.se/~joe/apachevsyaws.html
>>
>> One thing Yaws needs to improve is embedding.
>>
> Speaking from experience: Embedding yaws or cowboy is dead easy.

This thread is a few days old now, but I wanted to remark. I
integrated yaws into one of my releases a few years ago and I do have
to admit that it was difficult, but not in a hard to compile or link
or whatever kind of way, but in that all the documentation I found on
embedding was out of date and did not work. Eventually I found the
magic incantation to get yaws to embed and it was indeed rather dead
easy. Nowadays I still use yaws as an embedded web server, but I am
starting another project that will be using a few binary and one
textual data format on the wire, and I think that I will look at
cowboy for it to see how well it will fit, and yes I will still likely
have yaws embedded in it (as I already have a few 'management'
interfaces for my systems made in it). They each seem to be different
in what they supply and I welcome both.

And for note, I quite love yaws, but one thing that it really needs to
improve on is its documentation. ;)

[Steve Vinoski]

On Wed, Feb 22, 2012 at 10:29 PM, OvermindDL1 <overm...@gmail.com> wrote:
> On Sun, Feb 19, 2012 at 2:20 PM, Jesper Louis Andersen

> And for note, I quite love yaws, but one thing that it really needs to
> improve on is its documentation.  ;)

We welcome documentation patches as well as pointers to the
documentation problems that you feel need to be fixed.

--steve

[OvermindDL1]

On Wed, Feb 22, 2012 at 8:35 PM, Steve Vinoski <vin...@ieee.org> wrote:
> On Wed, Feb 22, 2012 at 10:29 PM, OvermindDL1 <overm...@gmail.com> wrote:
>> On Sun, Feb 19, 2012 at 2:20 PM, Jesper Louis Andersen
>> And for note, I quite love yaws, but one thing that it really needs to
>> improve on is its documentation.  ;)
>
> We welcome documentation patches as well as pointers to the
> documentation problems that you feel need to be fixed.

I should sometime. :)

Specifically it is not a lack of documentation, but rather just that
the documentation is spread out between multiple different areas and
even documentation within an area is not cross linked. The main thing
I remember from years ago (and that I still see today I think?) is the
gconf record did not seem to be linked anywhere, and certainly not
from the http://yaws.hyber.org/embed.yaws itself. It existed, I
remember that I found it, yet seem to be having trouble finding where
it was located again.

Basically just some sprinkling of links in the documentation is needed. :)

[Barco You]

It's much more urgent issue for the Cowboy to improve the documentation!

Barco