Yaws API discussion

Mickael Remond mickael.remond@REDACTED
Wed Jul 17 08:40:57 CEST 2002


Chris Pressey <cpressey@REDACTED>:

> 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.

> 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.
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.

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.

I think this is the real challenge here. And that is why collaboratively
thinking of the project evolution is necessary.
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.

> 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.

-- 
Mickaël Rémond



More information about the erlang-questions mailing list