Hello! On Mon, Oct 26, 2015 at 02:46:33PM -0700, Piotr Sikora wrote:
> Hey Maxim, > > > I don't think this change is needed. Current approach is in line > > with what's done for other headers, and I see no serious enough > > reasons to change things. > > Except that other headers (i.e. cache, ssl, v2) need to be included in > "core" http, because the functions they expose are used in "core" > http, whereas SSI is not. Basically, cache, ssl & v2 are all > compile-time options of the "core" http, whereas SSI is just an http > module and pulling SSI header in "core" http breaks layering & > separation of the modules. The SSI module is expected to be available for other modules to allow them to add their own SSI commands (like the perl module does). I don't see how making it available "breaks layering & separation of the modules". The question is only how you'll make it availble - either automatically as of now, or via additional #include when needed. > This doesn't really matter if you compile nginx as a big monolith, but > if you want to go DSO route or build modules separately from "core" > http, then "core" http (i.e. ngx_http.h) shouldn't be pulling headers > from non-"core" http modules. There are no plans to build all modules separately from core http. Rather, we are working on to allow building _some_ modules separately. And this mostly applies to modules with external dependencies (like perl, xslt, geoip) and 3rd party modules. And as perl depends on SSI, I don't think it will be possible to load SSI dynamically without significant changes to SSI's interface. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
