Access key module

[Grzegorz Nosek]

On Mon, Dec 31, 2007 at 11:00:33AM -0500, Evan Miller wrote:
> I'm not sure we'd need metadata. Modules should be guaranteed to work 
> with the Nginx version they ship with, and they can do their own library 
>  checking in their config scripts. (E.g. my Circle GIF module checks 
> for ImageMagick during ./configure.)

OK, I'm outnumbered ;) If the modules are to be kept in a single tree,
it would indeed be pointless. I rather thought of separately distributed
modules, but I like this way more.

> I too would prefer that the modules sit in a single tree. Perhaps a good 
> model is the Linux kernel: they have hundreds of modules written and 
> maintained by different people, but each one is approved by a number of 
> people before shipping. I personally think that most non-Igor modules 
> should sit in the main tree (src/http/modules), and the --add-module 
> mechanism should be used only for one-off or proprietary modules that 
> are privately maintained.

I don't think we (as the community) have enough resources to ensure
quality review of each other's code, so the modules will probably remain
more or less individual creations. As for putting external modules in
the main tree, this will make them look rather like a part of nginx
itself, which has both advantages and disadvantages, IMO. If we want to
distribute a pack of nginx modules, maybe we should keep them in a
structure parallel to original source, e.g. contrib-src/http/modules. Or
maybe not, just brainstorming :)

> We should talk to Igor about his attitude toward third-party modules. I 
> imagine he just doesn't have time to inspect, test, and integrate them. 
> If it makes things easier, I'd be willing to consolidate our modules 
> into a "community edition" and work with Igor to get changes accepted 
> upstream.

I'm not really sure about it. Nginx is still mostly a one-man project
and by integrating the modules into nginx core Igor would implicitly
gain responsibility for them. Although I'm all for integrating more
modules into core nginx, this should be (IMO) purely Igor's decision.
OTOH, I see the community edition as a wrapper adding stuff, which Igor
does not neccessarily want to see upstream, but which the community
finds valuable.

> Yes, it's time we had something more flexible than the Guide. I would 
> like both a low-level API reference and a high-level document more like 
> the Guide. For the low-level stuff, I think something like javadoc 
> parsed from the code would work best. (Another task for the "community 
> edition"?) For the high-level stuff, I rather like how the Django book 
> does it:

Well, the code is clean and rather self-documenting but comments are
pretty scarce, so an automated tool will probably extract just the
function prototypes. I think that a hand-written document with links to
the source (lxr for example) will do just fine.

IMO, the nginx source is pretty easy to follow at the low level (what
does this function do), but the big picture is way harder (where is X
handled), especially given the event-driven model and abundance of
callbacks. Thus (again, IMO) we should concentrate at the high level
description.

> 
> http://www.djangobook.com/en/1.0/
> 
> Each chapter has an individual author, but then anyone can leave 
> comments in the margins. I'd prefer this model to a wiki because 
> high-level guides are difficult to write, and their authors deserve 
> credit for their work.

<aol>I fully agree.</aol>

Best regards,
 Grzegorz Nosek