On Fri, Nov 20, 2009 at 5:42 PM, Piotr Sikora <piotr.sikora@frickle.com> wrote:
>> I might be able to package this up as a generic subrequest replacement. At
>> the very least, I'll clean up the code and post it somewhere for everyone's
>> perusal.
>
> Actually, I was going to do this myself over the weekend, so you could use
> "clean library"... I thought that you'll give subrequests some more time :P
>

I'm looking forward to that :D

> Anyway, what do you think would be better form for such "library" (from
> developer's perspective):
> - API module which would expose "fake request" functions to other modules
> (but it would require --add-module=/path/to/api and
> --add-module=/path/to/your/module)
> or
> - simple .c & .h files to include in your module and distribution?
>

I'm afraid the second method may give troubles given the current nginx
build system.

All the addon module's .o files are put under a single directory,
namely, objs/addon/src/. If two modules use two different versions of
your ngx_blah_blah_blah.c, then one of the .o will get overridden and
break that module's certain assumption. This will not be an issue,
however, if version numbers are coded into the .c file names, like
ngx_blah_blah_blah_v1.c :)

Personally I like the second method more because it reduces one
dependency on the end-user's side :)

Cheers,
-agentzh