Yaws API discussion

Chris Pressey <>
Thu Jul 18 09:57:35 CEST 2002

On Wed, 17 Jul 2002 08:40:57 +0200
Mickael Remond <> wrote:

> Chris Pressey <>:
> > 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.
> This is another aspect about Open Source that surely cannot be leveraged
> if there is one Open Source by user/developper. It implies that users
> and developpers make the effort to collaboratively think on how to
> improve the software and care about this improvment.

Sorry, I don't see your logic here.  A bug is a bug - it doesn't take a
group of people to determine that a program does not do what it claims to
do.  It takes just one person trying something no one else thought of.

(Unless the design goals are less than clearly specified - in which case,
the group will have to decide if the behaviour is a bug or a feature.  But
even then, it is still the core developers who will make that judgement.)

> > 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.
> In fact developping an HTTP server is fairly easy. It is also fairly
> easy to start a project.
> In fact the first reaction when looking at a project is often the
> following: people find often difficult to extend the code to make it
> comptible with their own need. So it is easy to conclude that the code
> may be poorly design and that rewriting the same thing from scratch will
> improve it.

This is *exactly* Klacke's rationale for yaws over php, btw.

> And it often and up with a code impleting nearly the same
> set of functions and that is difficult to extend and not very generic.

If it is a hack job, as so many projects are, yes it will be difficult to

But people who look at an existing piece of code and conclude that it is
poorly designed and that they could design something better usually try to
make something that is *less* of a hack job.  Sometimes they succeed.

The alternative is to try to patch the existing design, which may very
well break it and/or create some redundant (deprecated) functionality. 
The result is often ugly, complex, and even harder to understand and

Take Daniel J Bernstein's qmail as an example of the potential success of
a non-collaborative project.  It is elegant, reliable, generalized and
extensible.  It was written by one person and isn't even technically Open
Source software by OSI's definition, but I'd use it over sendmail anyday. 
I dread to think what the result would have been had he tried to adapt
sendmail to achieve his design goals!

> Actually, many open source project are launched and concentrate on easy
> parts. And then the author get to the point that this is more difficult
> to progress, to make it more generic and to cover more users needs
> because it is the easiest part has been developped and the next effort,
> extension and so on are the more difficult part.
> If everyone think this way, the difficult part will never be tackle.

But luckily not *everyone* works that way.  Some do, some don't.

I tend to think the most difficult part should be tackled before a single
line of code gets written.  Unfortunately not many Open Source developers
posess much foresight, and would rather take the expedient approach of
debugging a project into existence.

> I think this is the real challenge here. And that is why collaboratively
> thinking of the project evolution is necessary.

While feedback is always good, I think what this challenge warrants is
a well-thought-out, realistic plan *before* starting out.

> Oh sure, you need to discuss and find a compromise but when reached this
> compromise might lead to better code, more generic, and so on.
> When we developped the SOAP server we decided to implement our own http
> lib. This was a mistake and today I would build this project on an
> existing http server.
> For your specific need about user session, I think you should have a
> look at Inets. The design is modular and makes it possible to add such
> functionnalities on top of a full-feature and tested http server.

But (for example) I want users to be able to upload files with a
multpart/form-data form and to choke off the transfer with a 413 error if
the file size exceeds the user's quota.

How can this be done in Inets or yaws without resorting to a grody hack?

In fact (unless I am mistaken; I am not an expert at Inets or yaws code)
it seems that neither of these webservers store an uploaded file from a
multipart form in a temporary file as it is being recieved.  If a user
uploads a file many megabytes in size, it seems to me that storing it on
the heap could cause some severe problems with virtual memory swapping &c.
(This is guesswork though; I have yet to actually try this with them.)

> > 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.
> It might, but this risks should be taken to provide better tools.

Why is taking this risk preferable to taking the risk of starting over?

Forgive me, but you haven't shown why collaborative thinking is necessary,
you've just asserted that it is.  You've shown that it's difficult to turn
a hack job into an elegant, general solution, and I agree.  But it doesn't
automatically follow from that that a group effort makes it any easier to
turn a hack job into an elegant solution, or that an individual effort to
independently create a new elegant solution is wasteful.


More information about the erlang-questions mailing list