Access key module
manlio_perillo at libero.it
Mon Dec 31 17:47:13 MSK 2007
Grzegorz Nosek ha scritto:
> On Mon, Dec 31, 2007 at 12:55:23PM +0100, Manlio Perillo wrote:
>> I think that each external module should be kept separate from nginx "core".
>> An example is my mod_wsgi module, where I provide support for several
>> nginx version using patches.
> 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)
> 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).
Well, metadata is not required IMHO.
Since we have a full copy of the nginx sources, we can just modify the
auto configuration scripts, so that contrib modules became first class
modules (--with-wsgi-module, --with-upstream-fair-module, and so on).
> 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.
Keeping all in a single tree can be a good thing, but it will need a
rethink about how each developer handle its module.
>> However I can start to write single documentation pages for each of the
>> nginx "public" headers, and some documentation page for nginx
>> "astractions" and main concepts (events, process channels, buffer
>> chains, modules and configuration).
> 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.
But I don't want to just write reference documentation.
I want to use a bottom-up method, starting with documenting each header
files, and then integrating all the documentation.
This is, IMHO, more easy.
> Best regards,
> Grzegorz Nosek
Regards and happy new year Manlio Perillo
More information about the nginx