Access key module
emmiller at gmail.com
Mon Dec 31 23:13:12 MSK 2007
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
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
> 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
> 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
>> 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
More information about the nginx