This is very exciting! Among other things, this should make it practical for distributions to package individual nginx modules separately.
We've been looking at whether this would let us offer a precompiled ngx_pagespeed module, though, and it looks to me like this might be pretty tricky? In order to load a module, it looks like it has to have been compiled for that specific point release of nginx and with a matching signature? So we would need to make binaries for 1.9.11, 1.9.12, 1.9.13 etc and for each of those we would need to make ones for each of the common signatures [1]. That's a lot of binaries to prepare! Have you been thinking about any way that a module could be built to run against many versions of nginx, and many signatures, if it doesn't touch pieces of nginx that differ? With Apache, for example, we prepare 32 bit and 64 bit binaries for the 2.2 series and the 2.4 series (so 4 binaries). This works because we're calling into an ABI that Apache is committed to keep the same, but there might be some other way that would work better for nginx. Jeff Kaufman PageSpeed TL [1] With there being 33 bits in the signature, we're not going to be preparing 2^33 modules for each nginx release, but there are probably common patterns of build-time feature availability. On Tue, Feb 9, 2016 at 9:41 AM, Andrew Hutchings <ahutchi...@nginx.com> wrote: > Hi all, > > As you may have seen with recent code drops, we have released the initial > version of our Dynamic Modules code to the source tree and NGINX 1.9.11. > This initial release will allow you to compile modules with NGINX as before, > but can create shared object files at the same time as the NGINX binary. > These shared objects can then be loaded and unloaded at runtime. > > If you have any modules which you wish to use with this new feature they > will need a little work to convert them. Specifically the way the ‘config’ > file is written has changed. Although we have maintained compatibility with > the static compilation of modules so if you do not wish to convert a module > then you won’t have to change anything. Details on the new format and how to > convert the modules can be found at: > > https://www.nginx.com/resources/wiki/extending/ > > In addition we are working on fully documenting the module API with > examples. This will come at a later date. > > If you have any questions or problems converting modules please let us know > on this mailing list. > > Kind Regards > -- > Andrew Hutchings (LinuxJedi) > Technical Product Manager, NGINX Inc. > > _______________________________________________ > nginx-devel mailing list > nginx-devel@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-devel _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
