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. (:
/Uffe
--
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