Yaws API discussion

[Chris Pressey]

On Tue, 16 Jul 2002 20:03:47 +0200
Mickael Remond <mickael.remond@REDACTED> wrote:

> Chris Pressey <cpressey@REDACTED>:
> 
> > Even more unpopular opinion follows:
> > 
> > I don't see the big deal with yaws besides performance
> 
> Because I think that there is a need in a application server that is
> simple to use and code with and performant and I feel that it can be
> achieved by an Erlang development. All solutions that I know of are
> complicated and clumsy.

Fair enough.

I think

<erl> out(A) -> yaws_api:ssi(A#arg.docroot, ["/HEAD", "/TOPTAB"]). </erl>

is at least a *little* bit clumsy though.  :)

> For the rest, I tend to think that Open Source is about improving the
> tool that fit best your need at a given moment of time.

I think the success of Open Source has been more to do with widespread
peer-review.  More eyeballs on the code means more bugs are caught.

> What worries me is energy dispersion. Here is the list of Erlang HTTP
> server that I know of:
> - Inets 2
> - Inets 3
> - Pico
> - Yaws
> - possibly your incoming HTTP Server, Chris
> 
> So the main question is why develop another one ? Really ? You can
> choose one of those servers as a basis of improvement.  And writing
> another HTTP server, does not allow place for other cool improvement in
> the feature of those servers (like cool templating system, MVC approach
> modules, etc)

But one person's idea of a cool improvement is another person's cruft.
Why should I force my ideas on Klacke's project when it's clear that we
have different priorities?  Maybe he doesn't want an integrated cookieless
user system based on a database of IP addresses with timeouts, whereas I
do.  Maybe I could just take yaws and make my "improvements" to it, but
then I'd have Chris' Hacked Version of Yaws, which wouldn't be any better
than something original of mine.  In fact it would probably be worse in
the long run, as I can barely follow his code as it rapidly progresses.

> It would be cool to see an important Open Source Erlang project emerge
> as a collaborative work of many Erlang developpers, but this would
> probably not happen if we always rewrite everything when we need a piece
> of code (Even if this is easy in Erlang).

I think that's a bit of a pipe dream... in my experience, Open Source
projects are generally written and maintained by a small team of
developers, or even a single person; everyone else mainly just sends in
bug reports and suggestions.  Collaborative design tends to result in a
'too many cooks spoil the broth' situation in the pursuit of a 'one size
fits all' solution.

Basically, if I were going to worry about duplication of effort, I'd worry
more about how every Erlang programmer writes their own to_upper/1 et al
helper functions because they aren't found in stdlib :)

-Chris