Access key module

[Manlio Perillo]

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

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