Access key module

[Manlio Perillo]

Grzegorz Nosek ha scritto:
> On Mon, Dec 31, 2007 at 03:47:13PM +0100, Manlio Perillo wrote:
>> Grzegorz Nosek ha scritto:
> 
>>> 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.
> 
> Well, the modules might be in separate trees but should present a single
> interface for browsing, download, documentation and reporting bugs. This
> will be rather simple when all developers agree on a single RCS system,
> set up some bridge between them or hell freezes over ;)
> 

It's hard :).
I use Mercurial, you use Git, Adrian Perez (the author of fancy index) 
use Bazaar.


By the way: in the Third-Party HTTP modules list we should add the 
developer's names.


> Maybe we should choose an RCS that maybe even nobody uses personally,
> but has a decent web interface and can import/export repositories to all
> common systems.
> 
> What I'm aiming for (I guess) is a central place for nginx third-party
> modules, with one-click download of the whole pack, maybe some
> coordinated release schedule etc.
> 

For a central place it is not really required to have a shared RCS 
repository.

We can also just add a bug traker, restricted wiki pages with download 
links and a mailing list.

Maybe it is possible to write a wrapper for the nginx configuration that 
will be able to download external required modules (I have written, as 
an example, a wrapper for the nginx binary so that one can use the 
command line instead of a configuration file), configure them with an 
unified interface, and then call the configure script.


External modules that requires user configurable variables can use the 
OS environment, and the configuration wrapper will setup the environment 
for them.


 > [...]
> It seems I misunderstood you. I thought you want to just document the
> API. IMO a top-down approach is more informative. The low-level details
> can be quickly found by reading the source, while the big picture
> requires more time to "sink in".
> 
> Of course, as this is all OSS, the worst that happens if we disagree is
> that we end up meeting in the middle ;)
> 

Ok ;)

> Best regards,
>  Grzegorz Nosek
> 


Regards  Manlio Perillo