[erlang-questions] Misultin EOL

[unknown]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/52f7ef5e/attachment.html>

[unknown]

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.

Post by unknown
Dear list,
Misultin development has been discontinued.
There currently are three main webserver /libraries/ which basically do
* 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-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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<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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/f58789ee/attachment.html>

[unknown]

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

Post by unknown
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.

Post by unknown
Dear list,
Misultin development has been discontinued.
There currently are three main webserver /libraries/ which basically do
* 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-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

?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

[unknown]

Post by unknown

Post by unknown
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

[unknown]

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 <mjtruog>

Post by unknown

On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjtruog>

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

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.

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

Post by unknown

Post by unknown

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

On Fri, 17 Feb 2012 17:18:54 +1100, Michael Truog <mjtruog>

Post by unknown
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.

Post by unknown
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.

Post by unknown
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.

Post by unknown
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 -

Post by unknown

Post by unknown
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.
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 <mjtruog>

Post by unknown

On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjtruog>

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/6bc602c3/attachment.html>

[unknown]

Post by unknown
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

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.

Post by unknown
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

[unknown]

Post by unknown

Post by unknown
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.

Post by unknown
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.

[unknown]

Post by unknown

Post by unknown
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.

Post by unknown
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

[unknown]

Post by unknown
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

[unknown]

Post by unknown

Post by unknown

Post by unknown
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.

Post by unknown
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
http://www.scottberkun.com/blog/2008/stop-saying-innovation-heres-why/

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

Post by unknown
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. ;)

Post by unknown
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.

[unknown]

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

[unknown]

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

Post by unknown

Post by unknown
This is bad because unless people talk about what your project can do

then

Post by unknown
people new to Erlang won't know it. I'm relatively new to Erlang and

when I

Post by unknown
looked for a web server initially I didn't hear about Yaws.

erlang web server
and the Yaws home page is the very first link that popped up.
--steve
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/dd7ad0fa/attachment.html>

[unknown]

Post by unknown

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.

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.

[unknown]

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.

Post by unknown

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.

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

[unknown]

Post by unknown
In my opinion Yaws is the best Erlang web server and many new comers
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.

[unknown]

Post by unknown

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120219/429cfda1/attachment.html>

[unknown]

Post by unknown
In my opinion Yaws is the best Erlang web server and many new comers
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.

[unknown]

On Sun, Feb 19, 2012 at 2:20 PM, Jesper Louis Andersen

Post by unknown

Post by unknown
In my opinion Yaws is the best Erlang web server and many new comers
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. ;)

[unknown]

Post by unknown
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

[unknown]

Post by unknown

Post by unknown
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. :)

[unknown]

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

Barco

Post by unknown

On Wed, Feb 22, 2012 at 10:29 PM, OvermindDL1 <overminddl1>

Post by unknown
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. :)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120223/6108fa7b/attachment.html>

[unknown]

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 -

Post by unknown

Post by unknown
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

Very true, Ulf. And we'll get you that webmachine support soon.
And Michael, another way anyone can see how active yaws development is
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.

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/c69b56eb/attachment.html>

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/a7599e3a/attachment.html>

[unknown]

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

Post by unknown

Post by unknown
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.
. 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
. 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.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/d0c22cd7/attachment.html>

[unknown]

Post by unknown
. 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

Post by unknown

Post by unknown
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.
. 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
. 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.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown

Post by unknown
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

Very true, Ulf. And we'll get you that webmachine support soon.
And Michael, another way anyone can see how active yaws development is
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.

Post by unknown
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

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

[unknown]

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.

Post by unknown

Post by unknown
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

Very true, Ulf. And we'll get you that webmachine support soon.
And Michael, another way anyone can see how active yaws development is
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.

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questi...://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/eae4e591/attachment.html>

[unknown]

Post by unknown

?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]

[4]

[unknown]

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,
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

Post by unknown
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.

Post by unknown
Dear list,
Misultin development has been discontinued.
There currently are three main webserver /libraries/ which basically do
? * 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-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/c4cb3330/attachment.html>

[unknown]

Post by unknown

Post by unknown
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.

Post by unknown
r.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/91c333f2/attachment.html>

[unknown]

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

Post by unknown

Post by unknown

Post by unknown
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.

Post by unknown
r.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/75c3730e/attachment.html>

[unknown]

Post by unknown
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.

Post by unknown
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.

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/8f7d21e2/attachment.html>

[unknown]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/62d18004/attachment.html>

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/d2f7b390/attachment.html>

[unknown]

Post by unknown

Post by unknown
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.

It will stay - and be documented to make it official

/Joe

Post by unknown
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

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

Post by unknown

Post by unknown

Post by unknown
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

Post by unknown

Post by unknown
rid of it. What's the point of having something in a language if it's

not

Post by unknown

Post by unknown
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

Post by unknown

Post by unknown
indefinitely.

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

It will stay - and be documented to make it official
/Joe

Post by unknown
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/e52a81c9/attachment.html>

[unknown]

Post by unknown
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

Post by unknown
--
Jesse Gumm
Owner, Sigma Star Systems
414.940.4866
www.sigma-star.com
@jessegumm

Post by unknown

Post by unknown

Post by unknown
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.

It will stay - and be documented to make it official
/Joe

Post by unknown
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/1c059faa/attachment.html>

[unknown]

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

Post by unknown
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.

Post by unknown
r.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/40342450/attachment.html>

[unknown]

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!

Post by unknown

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/650b3d65/attachment.html>

[unknown]

Andrew,

Post by unknown
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!

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/b056377c/attachment.html>

[unknown]

Post by unknown
Andrew,

Post by unknown
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!
I think this new -callback stuff is more apt to solving the problem of
interfaces.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/fa2cfc54/attachment.html>

[unknown]

Post by unknown
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

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/e3937094/attachment.html>

[unknown]

Post by unknown
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.

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.

- beno?t

[unknown]

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.

[unknown]

Post by unknown
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.

Post by unknown
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.

[unknown]

Post by unknown
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

[unknown]

Post by unknown

Post by unknown
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
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

[unknown]

Post by unknown

Post by unknown
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

[unknown]

Post by unknown

Post by unknown
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.

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

Post by unknown
Cheers,
Tim
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/19cc6e56/attachment.html>

[unknown]

Post by unknown
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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/8886ccb9/attachment.html>

[unknown]

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.

Post by unknown
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

Post by unknown
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.

Post by unknown
Dear list,
Misultin development has been discontinued.
There currently are three main webserver /libraries/ which basically do
* 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-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

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

[unknown]

Post by unknown
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.

Post by unknown
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
On Fri, Feb 17, 2012 at 10:09 AM, Steve Davis <

Post by unknown
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
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/e2ef4e27/attachment.html>

[unknown]

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.

Post by unknown
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.

[unknown]

On Fri, 17 Feb 2012 13:09:45 +1100, Steve Davis

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

Me too!

Post by unknown
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.

Post by unknown
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 -

Post by unknown
Best regards,
/s
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/6fc54420/attachment.html>

[unknown]

Post by unknown
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.

/s

[unknown]

Post by unknown
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.

Post by unknown
Best regards,
/s
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/fc35169e/attachment.html>

[unknown]

On 17 February 2012 02:09, Steve Davis <steven.charles.davis>

Post by unknown
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

Post by unknown
Best regards,
/s
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

[unknown]

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.

Post by unknown

On 17 February 2012 02:09, Steve Davis <steven.charles.davis>

Post by unknown
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
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.
? ?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

Post by unknown
Best regards,
/s
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

[unknown]

Post by unknown
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,

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.

Post by unknown
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

Post by unknown

Post by unknown

On 17 February 2012 02:09, Steve Davis <steven.charles.davis>

Post by unknown
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
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.
? ?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

Post by unknown
Best regards,
/s
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

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

[unknown]

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

Sure, I understood that.

Post by unknown
? <?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.

Post by unknown

Post by unknown
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

[unknown]

Sad news Roberto.

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

Regards,
Zabrane

Post by unknown
Dear list,
Misultin development has been discontinued.
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.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/95df8056/attachment.html>

[unknown]

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.

Post by unknown
Sad news Roberto.
Anyway, thousands thanks for Misultin and hope you'll be still present to
help the community (if needed).
Regards,
Zabrane

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120216/42a65d2c/attachment.html>

[unknown]

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

Post by unknown
Dear list,
Misultin development has been discontinued.
There currently are three main webserver libraries which basically do
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.
_______________________________________________
erlang-questions mailing list
erlang-questions
http://erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120217/eb6c0b10/attachment.html>

[unknown]

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

----- Original Message -----

Post by unknown
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!
On Fri, Feb 17, 2012 at 3:03 PM, Tim Watson <

On 17 February 2012 22:49, Jesse Gumm < 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.

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/45ced786/attachment.html>