http rendering

Ulf Wiger etxuwig@REDACTED
Tue Jul 25 09:16:05 CEST 2000

On 24 Jul 2000, Lyn A Headley wrote:

>    Luc> 2) what is the interest of that approach , and drawbacks too
>    Luc> ?
>    Mickael> I think the advantage is that you can customized your
>    Mickael> application to exactly fit your need and then, you can
>    Mickael> put your apps in a single package, making your program
>    Mickael> very easy to use and install.
>    Mickael> The drawback is that you need to developp a program 
>    Mickael> supporting at least a subset of the http protocol.
>If you are talking about the "write your own webserver" approach, as
>taken by the erlang crew, there are a _lot_ of wheels to reinvent.
>You must not only replicate say, apache's work on the http protocol,
>but any additional functionality you might need as well, such as
>logging, SSL, cgi, persistent cgi-type stuff, url-rewriting,
>authentication, proxying, virtual hosts, etc etc etc. not to mention
>all the stuff that will come along in the future.  

Granted, and this is the main reason why the Erlang HTTP server is
made plug-compatible with Apache.

There is another use for Erlang web servers: acting as an operator
interface in embedded systems. For this purpose, it's perfectly
reasonable to roll your own, as you can make a web server with a very
small footprint in Erlang. For example, the HTTP server in the
CCviewer application I posted yesterday (which serves its purpose
pretty well) consists of only about 500 lines of code.

Still, if one would like to get into a feature race with Apache,
Erlang might be a good vessel for it -- esp. when the Bit syntax
comes along. (:

Ulf Wiger                                    tfn: +46  8 719 81 95
Network Architecture & Product Strategies    mob: +46 70 519 81 95
Ericsson Telecom AB,              Datacom Networks and IP Services
Varuvägen 9, Älvsjö,                    S-126 25 Stockholm, Sweden

More information about the erlang-questions mailing list