apache and yaws

Joe Armstrong (AL/EAB) joe.armstrong@REDACTED
Wed Jan 25 14:55:17 CET 2006


Absolutely, though I see no reason for the "must" in our statement
"the must be things it (Apache) does better than yaws"

Now Apache does things that yaws does not do at all - but
when you can get Apache and yaws to do the same thing (like serving up
dynamic content) yaws seems to outperform Apache.

I guess we could ask - what features are missing from yaws that have
proved to be
useful in Apache - and then set about and implement them.

Apart form that I haven't quite understood why a server must be a server
for ONE
thing. Why do we have FTP servers, HTTP servers, email server, etc.

Why not a universal server, with an FTP plugin, and HTTP plugin, etc.
(( I built one of these a while back :-)) - it was just an empty server
that did nothing - the only thing you could do with it was to sent it
code, and then it became whatever the code you sent it told it to do.

So you could send it code meaning "become an FTP server" and it then was
an FTP server ...

As regards Apache, I'd like to broaden the scope. 


Here's the plan.

Replace Apache + MySQL  + PHP    with
        Yaws   + Mnesia + Erlang 

Why?

	Yaws   outperforms Apache 
	Mnesia outperforms MySQL  
	Erlang outperforms PHP    

<< I could add lots of footnotes here, since these statements need some
qualifying, ie mnesia is better than SQL for real-time lookups, yaws
better than apache
under overload conditions etc. Erlang seems to outperform PHP for
everything :-) >> 

Also, and more importantly, *the bits fit together properly* - ie there
is no semantic gap between Yaws/mnesia/PHP.

To make an Apache, MySQL, PHP application you have to learn three,
(yes you heard me right, three) different languages and sets of
configuration files.

This is *painful* there are even entire BOOKs devoted to setting up
Apache, MySQL and PHP.

What should be a *trivial* operation of making a web sever work
together with a database and a scripting language becomes an
nightmare exercise of fitting different versions of things together.

I tried this once - it was terrible. You have to get exactly the right
versions of everything and mess around editing things for ages, until it
finally
works - no wonder these things come pre-installed or as add-on packages
in every  
half decent OS release - doing it yourself is a bummer.

Now the Yaws-mnesia-Erlang install is a *lot* easier.

Make Erlang work. Take the yaws tarball, unpack, run.

Making it into a system daemon is a bit more tricky - 20 mins or so.

Now the nice thing about the yaws/mnesia/Erlang setup is the conceptual
framework - THE BITS FIT TOGETHER - I cannot overstress this point
(it's called conceptual integrity).

What we currently don't have is an "enterprise yaws" (ie one that will
let multiple
users use the same yaws in a safe manner so that they can't crash each
other's applications)
nor do we have a decent template language, nor do we have Ajax things
etc.

All of these are being worked on, and prototype solutions for safe
Erlang code within Erlang
and for various template languages are "in progress".

Hopefully these will be in releasable shape fairly soon.

Right now I'm finalising some wiki and template modules to add to yaws
and trying to move the entire Erlang documentation system into a 
wiki + yaws + blog + forums engine.

Cheers

/Joe

> -----Original Message-----
> From: owner-erlang-questions@REDACTED 
> [mailto:owner-erlang-questions@REDACTED] On Behalf Of bryan 
> rasmussen
> Sent: den 25 januari 2006 13:46
> To: erlang-questions@REDACTED
> Subject: apache and yaws
> 
> Hi,
> 
> A lot of people have referenced the apache vs. yaws 
> discussion over the years, what I'm wondering about is Apache 
> and Yaws. Has anyone thought of any particular integration 
> scenarios between these two. I have to admit I haven't 
> either, but I would think that despite the scalability of 
> yaws that Apache's list of components are impressive, there 
> must be things it does better than Yaws.
> 
> Any ideas?
> 
> Cheers,
> Bryan Rasmussen
> 



More information about the erlang-questions mailing list