[erlang-questions] Misultin EOL

Fri Feb 17 08:37:32 CET 2012

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

> The modularity/usability issues mainly seem to be related to the fact  
> that I see it as overkill for most projects that I would be interested  
> in.  So, this is a subjective judgment, where I don't want to get locked  
> into an obscure templating format, etc.

I see.

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

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

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

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

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

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

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

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

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

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

- Edmond -

> On 02/16/2012 09:52 PM, Edmond Begumisa wrote:
>> 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@REDACTED>  
>> wrote:
>>
>>> On 02/16/2012 01:17 PM, Steve Vinoski wrote:
>>>> On Thu, Feb 16, 2012 at 3:50 PM, Michael Truog <mjtruog@REDACTED>  
>>>> wrote:
>>>>>  Is cowboy going to be able to take the lead on HTTP Erlang web  
>>>>> server performance where mochiweb and yaws have been unable to  
>>>>> (please don't bother to flame this, those people that don't care  
>>>>> about performance, but care about Erlang)?
>>>> I'm not interested in flames either, but I am interested in facts.
>>>> Please back up your assertion by posting your meaningful benchmarks
>>>> that prove that Yaws is lacking in performance.
>>>>
>>>> thanks,
>>>> --steve
>>>
>>> It is unfair to say that yaws does not perform like misultin and I do  
>>> not have data to make that statement.  When I think of performance, I  
>>> am also thinking of software development performance for modifying,  
>>> extending, and using the code-base.  Yaws has lacked support once  
>>> mochiweb was available because of some fragmentation within the  
>>> community.  From what I have seen, yaws chooses not to focus on  
>>> performance, and has never intended to do so in the past, so it is  
>>> unclear whether it would be able to maintain its performance in the  
>>> future, if it received more support (based on  
>>> http://steve.vinoski.net/blog/2011/05/09/erlang-web-server-benchmarking/).   
>>> So, that was misleading for me to say, since you are probably correct  
>>> that misultin is on par with yaws, though there are no public results  
>>> to show that.  With yaws the concern seems to be more about the code  
>>> being regarded as legacy, not actively developed, and not modular (and  
>>> whatever other reasons that seemed to make mochiweb
>>> appear necessary).  I say this knowing that you are currently the main  
>>> maintainer of the code-base.  These are just the impressions I have  
>>> had from being within the Erlang community for a few years.
>>>
>>> - Michael
>>>
>>> _______________________________________________
>>> erlang-questions mailing list
>>> erlang-questions@REDACTED
>>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>
>

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