On Mon, Dec 31, 2007 at 12:55:23PM +0100, Manlio Perillo wrote:

I think that it might be useful to keep an official contrib module list. If nothing else, it should increase confidence in these modules.

The directory layout could look e.g. like: src/ (nginx source) contrib/ mod_wsgi-0.5/ mod_wsgi-0.6/ upstream_fair/ whatever/

We could/should also keep some metadata about the modules (required nginx version, required extra libraries, etc.) in an easily parsable format for some future tool to include them in the build process (maybe patch-o-matic style but simpler).

I'm not going to fight about putting them in a single tree (though I'd like it), but I think they should all be accessible from a single place with a unified interface. IMO this makes them look more polished than a bunch of links (an svn here, a tarball there etc.). However, this would require a certain amount of coordination between module authors.

Yes, Igor's blessing would be neccessary for the project to be deemed official. However, if we aggregated some third-party modules and provided a common interface to them, I'd be reluctant to call it a fork. A frontend or "community edition" maybe. Realistically, we cannot expect Igor to maintain the external modules, so the level of support we'd *need* would be "lack of open hostility" ;) and accepting bug reports from the tracker. Of course, his input into the documentation would be invaluable.

I bet :) upstream_fair is a pretty small module but I had to dig through almost all the nginx code to get it up to shape.

- Hi, I'm Greg, and I'm a bad writer too. - (all together) Hi, Greg!

I think that documenting headers is less useful than the bigger picture. This is IMHO a major deficiency in many OSS projects, which document every class/function via doxygen and call it a day. E.g. to use shared memory in nginx, you need not only to allocate a segment and use it, but also wire it up in such a way that subsequent reloads don't trash it or cause leaks etc. Even the best documentation for a single function won't cut it (again, IMHO). I'd like the documentation to be task-oriented, i.e. "How do I write a handler?", "When and how should I use rbtrees?", etc. It could then serve as a sequel to the Guide.