Access key module

[Evan Miller]

Grzegorz Nosek wrote:
> On Mon, Dec 31, 2007 at 11:00:33AM -0500, Evan Miller wrote:
>> 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 :)
>

I think we're talking about three separate problems:

1. Distributing community modules to end-users.

2. Marking community modules as "stable."

3. Distributing community modules/patches to developers.

We can achieve #1 with a community edition of some sort. I hesitate to 
do it because modules often require patches to the nginx core (modifying 
data structures, etc.), and this may cause some confusion among 
end-users especially when bugs arise, then it might need its own mailing 
list, and things get hairy. There's also the question of what goes in 
the community edition and who decides (the malicious code problem).

#2, marking modules as "stable," does require some work; either Igor 
needs to review them and accept them into the official nginx download, 
or we need some sort of peer-review process so that outsiders can trust 
the community edition. I do think it's essential that modules be able to 
graduate to "first-class" status, but we will need Igor's cooperation. I 
am curious to hear about Igor's willingness to integrate third-party 
modules.

For #3, distributing modules and patches among developers, I again like 
the Linux kernel model: everyone keeps their own copy of the source, and 
posts the changes they make to a mailing list. To get updates, you just 
pull from developers you trust.

#1 and #2 are not trivial problems. My inclination is to solve #3 first 
and build a proper developer community; then the solutions to #1 and #2 
might become more obvious. It might be that one developer's branch 
becomes the de-facto "community edition (testing)", and another 
developer's branch becomes the de-facto "community edition (stable)". In 
any event, we'll get a clearer idea of how many people are interested in 
testing and integrating.

BTW, I vote for git. :)

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

Well, Igor could delegate responsibility for individual modules to their 
original authors. When questions or bugs come up, then that person is 
responsible for dealing with them. If a module is causing problems and 
that person is delinquent in addressing issues, Igor can just rip the 
module out until a new owner is found. But it again depends on whether 
he's willing to move beyond a one-man project.

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

I don't entirely agree. Some functions do a lot of work and I would have 
appreciated a sentence or two in summary. However, in these cases 
perhaps refactoring the code would be more useful than commenting it. I 
do agree that we should start with an organized list of function 
prototypes and constants, and spend most of our energies on high-level 
descriptions.

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

(What's aol?)

Evan

> 
> Best regards,
>  Grzegorz Nosek
> 
>