> Earlier in this thread we have this gem from Loïc: >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough >> momentum to introduce innovation in Erlang web servers.
I'm sorry if you misunderstood this but you also provide the reason why I have that opinion.
> Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for.
Misultin and Cowboy are still at a point in the projects' life where features continue being added or improved before users request them, not the other way around. They can also afford to break the API a little if a better solution exists, since both of them aren't considered stable at this point.
On Thu, Feb 16, 2012 at 3:17 PM, Steve Vinoski <vino...@ieee.org> wrote: > On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjtr...@gmail.com> wrote: >> Is cowboy going to be able to take the lead on HTTP Erlang web server performance where mochiweb and yaws have been unable to (please don't bother to flame this, those people that don't care about performance, but care about Erlang)?
> I'm not interested in flames either, but I am interested in facts. > Please back up your assertion by posting your meaningful benchmarks > that prove that Yaws is lacking in performance.
FWIW, I spent some time looking at HTTP servers a couple years ago in developing Landshark [1], which uses Mochiweb.
I found that *any* Erlang HTTP server, and certainly YAWs, was decisively both faster and more resilient to faults than the other language environment options I looked at, which the exception of mod_php, which also fared very well. [2]
That said, I place little credence in these sorts of benchmarks. They provide data, but it's not always clear what you can correctly infer from them. We do have a tendency to get our rulers out and start measuring, even if what we're measuring is completely pointless [3].
I've also observed that developers will, for whatever reason, go to incredible lengths to eek out even the slightest performance gains in the web tier [4]. In every large scale Web application I've seen though, the web tier is not a bottleneck -- it's the data tier that gives us fits. Of course there are exceptions, but if performance is that critical, there's C!
Garrett
[1] Landshark was my first Erlang project and is now totally defunct. I'm a proponent of modlib - https://github.com/gar1t/modlib - which is a supplement to Erlang's built in httpd server.
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.
On Sat, 18 Feb 2012 02:06:11 +1100, Steve Vinoski <vino...@ieee.org> wrote: > On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
>> On 17 Feb 2012, at 00:06, Michael Truog wrote:
>> With yaws the concern seems to be more about the code being regarded as >> legacy, not actively developed, and not modular (and whatever other >> reasons >> that seemed to make mochiweb >> appear necessary).
>> I think this is no longer true. My impression is that yaws development >> has >> picked up again, Looking at the change log for the releases in the past >> year >> or two [1], it is obvious that it is being actively maintained. This is >> also >> apparent from the github stats [2]. And yaws now comes with generic >> support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :)
> This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development.
> Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action.
> Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible.
> Earlier in this thread we have this gem from Loïc: >> I'm sad to see Misultin go, this was in my opinion the only other >> project that had enough >> momentum to introduce innovation in Erlang web servers.
> Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Loïc don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there.
> Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that.
> Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems?
> On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
>> I think this is no longer true. My impression is that yaws development has >> picked up again, Looking at the change log for the releases in the past year >> or two [1], it is obvious that it is being actively maintained. This is also >> apparent from the github stats [2]. And yaws now comes with generic support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :)
> 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. ;-)
> On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger <u...@feuerlabs.com> wrote: >> On 17 Feb 2012, at 00:06, Michael Truog wrote:
>> With yaws the concern seems to be more about the code being regarded as >> legacy, not actively developed, and not modular (and whatever other reasons >> that seemed to make mochiweb >> appear necessary).
>> I think this is no longer true. My impression is that yaws development has >> picked up again, Looking at the change log for the releases in the past year >> or two [1], it is obvious that it is being actively maintained. This is also >> apparent from the github stats [2]. And yaws now comes with generic support >> for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even >> WebSockets. One of the few things I miss is WebMachine support. :)
> This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development.
> Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action.
> Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible.
> Earlier in this thread we have this gem from Loïc: >> I'm sad to see Misultin go, this was in my opinion the only other project that had enough >> momentum to introduce innovation in Erlang web servers. > Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Loïc don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there.
> Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that.
> Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems?
> --steve
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.
On Fri, Feb 17, 2012 at 6:39 AM, Joe Armstrong <erl...@gmail.com> wrote: > Thanks for all your hard work Roberto - I've been a fan > of Misultin for a while now. I always choose the code > with the best documentation since I don't care about efficiency.
> So thanks once again for your efforts.
and thank you for using misultin in the first place ^^_ websocket supports was first added thanks to a post you did on your blog regarding this, some time ago now.
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.
On Feb 17, 4:06 pm, Steve Vinoski <vino...@ieee.org> wrote:
> On Fri, Feb 17, 2012 at 3:59 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
> > On 17 Feb 2012, at 00:06, Michael Truog wrote:
> > With yaws the concern seems to be more about the code being regarded as > > legacy, not actively developed, and not modular (and whatever other reasons > > that seemed to make mochiweb > > appear necessary).
> > I think this is no longer true. My impression is that yaws development has > > picked up again, Looking at the change log for the releases in the past year > > or two [1], it is obvious that it is being actively maintained. This is also > > apparent from the github stats [2]. And yaws now comes with generic support > > for the various forms of JSON RPC (1.1 and 2.0), HAXE, SOAP, and even > > WebSockets. One of the few things I miss is WebMachine support. :)
> This approach would seem vastly preferable to spreading inaccurate and > irresponsible rumors on this mailing list about yaws not being > actively developed. I've been using yaws for the past 5 years, much of > it in a production embedded system, and it's been actively developed > for all 5 of those years. Yaws is now in its 11th year of active > development.
> Regarding yaws modularity, I keep hearing this rumor that it lacks in > that regard, yet nobody has yet pointed out any specifics. If someone > were to point out things they think are too intertwined, then Klacke, > Christopher Faulet, or I -- those with commit rights to the yaws repo > -- could at least consider fixing them, as could anyone else with an > interest in providing a patch. But in the absence of anything > concrete, it's hard to take action.
> Note that the production embedded system I mentioned earlier doesn't > use SOAP or haxe or websockets or numerous other yaws features, and in > fact doesn't even include them, plus it runs embedded within a larger > application, not as a stand-alone server. If it truly lacked > modularity, or if it weren't usable in a library-like fashion, none of > that would be possible.
> Earlier in this thread we have this gem from Loïc:
> > I'm sad to see Misultin go, this was in my opinion the only other project that had enough > > momentum to introduce innovation in Erlang web servers.
> Wow. At best, this is simply ignorant on several fronts. At worst, > it's insulting to Klacke, Bob Ippolito, me and others who've put a lot > of work into their Erlang web servers and continue to do so. Hell, > Erlang wouldn't be where it is today without all the features Klacke > put into it, and I doubt Erlang web systems would be as far along as > they are now without Klacke's and Bob's continued contributions and > deployments into real products in years where most of us hadn't even > started using Erlang yet. Part of the reason Roberto has taken this > new action regarding misultin is that he wants the Erlang web > community to become more cohesive, reusing each other's work instead > of competing with each other, but irresponsible statements like this > one from Loïc don't help Roberto's cause at all. If we truly want the > Erlang web dev community to become less fractured so it can grow, > taking cheap shots at each other won't get us there.
> Yaws exists and continues to exist because people continue to use it > in real-life production systems. Klacke, Christopher, and I all have > day jobs, so whatever time we put into yaws is based on what users are > asking for. What makes it real interesting and fun is to fit new > features like websockets into a system without it being an ugly hack > and without breaking everything else that's already there, and we > intend to continue to do exactly that.
> Perhaps worst of all about parts of this thread, though, is that from > what I've seen over the past few years, those spreading these > unfounded rumors about yaws being old and creaky and slow and legacy > and not actively developed and not usable for their projects never > once contacted Klacke or me or the erlyaws mailing list about > questions or issues with the system. They've never attempted to > contribute to the system with features or patches. I therefore suspect > that they just listened to the same recurring unfounded gossip and > made up their mind that way. Unfortunate, if true. But surely it's not > asking too much to request that, going forward, people at least do > their homework, try things out, and maybe ask some questions before > stating "facts" that simply aren't true about yaws, or mochiweb, or > any other such systems?
On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
> FWIW, as has perhaps become evident, as we needed to pick a web server > here at Feuerlabs, we had an open-ended discussion about the different > alternatives, then decided to go with Yaws. First off, we will do our best > to steer clear of tying ourselves to hard to any particular web server API, > but I don't see that as a big problem. If we decide to change later on, it > will be a small effort in our case.
> We chose to start with yaws for exactly the reasons that have come up > here. It's battle-proven, has remained stable over the years, and doesn't > appear to have any big problems keeping up with the new kids on the block > in terms of speed (at least within the margin of uncertainty given that > Yaws really does strive hard to be fully compliant - something that means > something to us, as it will be the point of interface for our external > customers).
> What impresses with Yaws is its long track record and feature list, and a > quick look at the development activity made it obvious that it is being > very well looked after.
> That said, the energy around Cowboy is impressive too. Our choice was not > a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have > other fish to fry.
this is exactly why i took misultin out of the picture.
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.
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
On Fri, Feb 17, 2012 at 1:11 PM, Roberto Ostinelli <robe...@widetag.com>wrote:
> On Fri, Feb 17, 2012 at 8:10 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
>> FWIW, as has perhaps become evident, as we needed to pick a web server >> here at Feuerlabs, we had an open-ended discussion about the different >> alternatives, then decided to go with Yaws. First off, we will do our best >> to steer clear of tying ourselves to hard to any particular web server API, >> but I don't see that as a big problem. If we decide to change later on, it >> will be a small effort in our case.
>> We chose to start with yaws for exactly the reasons that have come up >> here. It's battle-proven, has remained stable over the years, and doesn't >> appear to have any big problems keeping up with the new kids on the block >> in terms of speed (at least within the margin of uncertainty given that >> Yaws really does strive hard to be fully compliant - something that means >> something to us, as it will be the point of interface for our external >> customers).
>> What impresses with Yaws is its long track record and feature list, and a >> quick look at the development activity made it obvious that it is being >> very well looked after.
>> That said, the energy around Cowboy is impressive too. Our choice was not >> a vote *against* Cowboy, but rather a vote of confidence for Yaws. We have >> other fish to fry.
> this is exactly why i took misultin out of the picture.
> 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.
> 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.
> On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>> Not to state the obvious or anything, but Misultin is open source, so >> someone could always step up to the plate and become the *official* >> fork.
>> There will still be efforts to support Misultin: Chicago Boss uses it, >> and barring some serious arguments against it, I'll still be adding >> misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 >> release.
>> So while it's unfortunate that Roberto is stepping away from Misultin >> development, that doesn't mean it's necessarily dead - someone can >> always take over.
>> -Jesse
> hi jesse,
> please don't suggest that. while i cannot avoid someone doing so, i could > have kept maintaing misultin myself. as i said, it has been a hard decision.
> my intent here is to avoid duplication of efforts, both for the > contributors of the community (often reporting the same bugs in both > repositories) and for the developers, which now have an hard time in > deciding which way to go.
> i just wanted to clear the way for a single webserver library, and cowboy > seems to have much more developer time to actually maintaining it.
Personally I don't understand why having a single library is so great, although I respect your decision to do this and am very grateful for all the hard work you've put into misultin to date.
In *java-land* I like being able to choose between Tomcat, Jetty (for embedded stuff) and other commercial options too. I don't see why it's a bad thing at all, although I would *really* love it if Erlang had just one API for building standard web applications (a la servlets, but obviously more 'erlang-ish' in flavour) and then interesting stuff like Chicago Boss can be built on top of it.
Personally I'm not keen on simple bridge because I don't like parameterised modules, but in every other respect I think it's a laudable effort. If we could standardise on an API - and god knows, I *really like* the one in Cowboy - then I personally think that would provide more benefit than having 'just one implementation'. Personally I don't think having just one implementation is the answer though.
On 17 February 2012 15:06, Steve Vinoski <vino...@ieee.org> wrote:
> Very true, Ulf. And we'll get you that webmachine support soon.
I'll jump on YAWS in a second, once that webmachine support is available. YAWS maturity is a big selling point for me. Most of the time, I don't want to think about generating HTML. Most of the web applications we've built at work are RESTful web services, which serve up either XML, JSON or both. None of them actually serve web pages - we have static HTML/Javascript content served up by nginx in front of Mochiweb/Misultin that makes ajax calls to the back end. Another feature that we rely on is streaming (or chunking) the response back to the client, which YAWS appears to do very nicely.
I'd still really like it if all these applications had a consistent API though. One thing I really appreciate about YAWS and Cowboy is that they both avoid parameterised modules. Not that I care one way or the other about whether parameterised modules are good or bad TBH, just that they're not officially supported and that puts me off.
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
On Fri, Feb 17, 2012 at 2:16 PM, Tim Watson <watson.timo...@gmail.com>wrote:
> On 16 February 2012 22:05, Roberto Ostinelli <robe...@widetag.com> wrote:
>> On Thu, Feb 16, 2012 at 1:42 PM, Jesse Gumm <g...@sigma-star.com> wrote:
>>> Not to state the obvious or anything, but Misultin is open source, so >>> someone could always step up to the plate and become the *official* >>> fork.
>>> There will still be efforts to support Misultin: Chicago Boss uses it, >>> and barring some serious arguments against it, I'll still be adding >>> misultin support to Nitrogen and SimpleBridge for the upcoming 2.1.0 >>> release.
>>> So while it's unfortunate that Roberto is stepping away from Misultin >>> development, that doesn't mean it's necessarily dead - someone can >>> always take over.
>>> -Jesse
>> hi jesse,
>> please don't suggest that. while i cannot avoid someone doing so, i could >> have kept maintaing misultin myself. as i said, it has been a hard decision.
>> my intent here is to avoid duplication of efforts, both for the >> contributors of the community (often reporting the same bugs in both >> repositories) and for the developers, which now have an hard time in >> deciding which way to go.
>> i just wanted to clear the way for a single webserver library, and cowboy >> seems to have much more developer time to actually maintaining it.
> Personally I don't understand why having a single library is so great, > although I respect your decision to do this and am very grateful for all > the hard work you've put into misultin to date.
> In *java-land* I like being able to choose between Tomcat, Jetty (for > embedded stuff) and other commercial options too. I don't see why it's a > bad thing at all, although I would *really* love it if Erlang had just one > API for building standard web applications (a la servlets, but obviously > more 'erlang-ish' in flavour) and then interesting stuff like Chicago Boss > can be built on top of it.
> Personally I'm not keen on simple bridge because I don't like > parameterised modules, but in every other respect I think it's a laudable > effort. If we could standardise on an API - and god knows, I *really like* > the one in Cowboy - then I personally think that would provide more benefit > than having 'just one implementation'. Personally I don't think having just > one implementation is the answer though.
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.
> 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.
On 17 February 2012 22:42, Andrew Berman <rexx...@gmail.com> wrote:
> Tim,
> I think a comparison between the Java app servers is not really accurate. > The reason I say that is that most have commercial support. Tomcat might > be the only one without commercial support, but it's the reference > implementation and has plenty of books about it. As far as I know with all > the other popular ones there is some company who's willing to support it. > I think that's a big difference here between comparing Java app servers > and Erlang servers. Misultin is completely open-source with one man > supporting it and no commercial support. I'd much rather see fewer servers > with better support and possibly commercial support than many with little > support.
Yes ok, you make a very good point there. I hadn't thought about that, and on a few minutes reflection, I think you're quite right.
> I do agree completely that Erlang needs a consistent servlet-like API. It > would certainly help a lot.
Yes. There database libraries need this too. Java might be pants, but there are a few good things we can learn from it, and consistent APIs are one of them.
> I'd be keen on simple bridge if the Erlang guys would just come out and > say if they support parameterized modules or not. If they don't, just get > rid of it. What's the point of having something in a language if it's not > going to be supported (but that's a different topic)?
Yes indeed, same here. Personally I actually find them rather unintuitive, but I'd use them more readily in other people's libraries if they were properly supported. We've actually got Misultin running in production and it's been great, so it's not that I'm completely allergic to parameterised modules, just that I would prefer not to have them in an API.
On 17 February 2012 22:49, Jesse Gumm <g...@sigma-star.com> wrote:
> I agree with you about the parameterised modules. I'm not a big fan > of them either (though seeing how it works, I do understand why Rusty > went that route), and the deprecation of the tuple modules had me > scared for a moment. After that happened, I've been starting to think > about a roadmap away from the parameterised modules with > simple_bridge.
I think that's a good idea.
I would also like to respectfully suggest that api implementations might be distributed separately from the api itself, so that I can choose to get simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other stuff. Just a suggestion you may wish to consider.
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 <watson.timo...@gmail.com>wrote:
> On 17 February 2012 22:49, Jesse Gumm <g...@sigma-star.com> wrote:
>> I agree with you about the parameterised modules. I'm not a big fan >> of them either (though seeing how it works, I do understand why Rusty >> went that route), and the deprecation of the tuple modules had me >> scared for a moment. After that happened, I've been starting to think >> about a roadmap away from the parameterised modules with >> simple_bridge.
> I think that's a good idea.
> I would also like to respectfully suggest that api implementations might > be distributed separately from the api itself, so that I can choose to get > simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other > stuff. Just a suggestion you may wish to consider.
>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.
On 17 February 2012 23:31, Yurii Rashkovskii <yra...@gmail.com> wrote:
> Andrew,
> >I think a lot of issues with APIs would be solved if we had something > analogous to Java interfaces in Erlang. Behaviors just don't cut it. I > want something that is a replica of interfaces. Then all the Erlang guys > have to do is create the interface and then people can create whatever > implementations they want and I never have to worry about changing my code!
> 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
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.
On Sat, Feb 18, 2012 at 12:03 AM, Tim Watson <watson.timo...@gmail.com> wrote: > On 17 February 2012 22:49, Jesse Gumm <g...@sigma-star.com> wrote:
>> I agree with you about the parameterised modules. I'm not a big fan >> of them either (though seeing how it works, I do understand why Rusty >> went that route), and the deprecation of the tuple modules had me >> scared for a moment. After that happened, I've been starting to think >> about a roadmap away from the parameterised modules with >> simple_bridge.
> I think that's a good idea.
> I would also like to respectfully suggest that api implementations might be > distributed separately from the api itself, so that I can choose to get > simple_bridge and simple_bridge_mochiweb (or whatever) but ignore the other > stuff. Just a suggestion you may wish to consider.
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.
On Fri, Feb 17, 2012 at 11:12 PM, Tim Watson <watson.timo...@gmail.com> wrote: > On 17 February 2012 02:09, Steve Davis <steven.charles.da...@gmail.com> > wrote:
>> Hi Roberto,
>> I'm a bit confused by this whole thread...
>> I'm agreeing with Jesse that since Misultin is open source, it's not >> really in your control to "stop development" if the interest is there >> elsewhere to push it on?
>> I'm also agreeing with Steve that I've not seen any demonstration that >> yaws is somehow "lacking",
>> For me, the last interesting benchmark that demonstrated anything >> graspably real was "yaws vs apache".
>> A really interesting benchmark for today's "web server" would be, if >> someone were willing to engage in a non-trivial effort, to make a >> comparison of a full-fledged web application with full session >> management and routing capabilities. Note that this would truly test >> the appropriateness of the server's http APIs as well as the base >> response. That kind of benchmark, for me, would seem more appropriate >> and useful according to the epoch.
> I've been suggesting this for some time now. I will make some time (somehow) > to participate and I'm sure others will too.
Yes ^ 100
My *minimal* application does this for *every* GET request
1) Is there a cookie? 2) If no cookie redirect to a set-cookie page 3) if there is a cookie lookup value in database 4) if no value in DB redirect to warning page 5) if there is a value check if user is authenticated 6) if not authenticated redirect to login page 7) if authenticated lookup same basic data about user in DB 8) send the result
I suspect that impedance mismatches between the DB and web server are the main sources of inefficiency
The *interesting* benchmark is (say) the number of page-views in a forum/second or the number of searches/second in a forum.
We need to implement something like PHPBB and benchmark the number of page-views/second (Actually doing so would involve even more work before a page gets sent - is the IP blacklisted? - has the user posted more than N requests in the last T seconds - is the user a spammer...)
One thing that hinders this is the lack of a common language to implement the web-part in. I have made a little language EHE for this - which included in my adapter pattern - EHE is easy to embed in *any* erlang web server - I have done so for misultin, cowboy and mochiweb see
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
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)
> 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'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.
On Sat, Feb 18, 2012 at 12:05 PM, José Valim <jose.va...@gmail.com> wrote: >> I'd be keen on simple bridge if the Erlang guys would just come out and >> say if they support parameterized modules or not. If they don't, just get >> rid of it. What's the point of having something in a language if it's not >> going to be supported (but that's a different topic)?
>> I agree that if something is added as an experimental feature, it should >> either be graduated or removed as soon as possible, not stay experimental >> indefinitely.
> 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
