NGINX Dynamic Modules

[Maxim Dounin]

Hello!

On Tue, Feb 09, 2016 at 01:45:46PM -0500, Jeff Kaufman wrote:

> This is very exciting!  Among other things, this should make it
> practical for distributions to package individual nginx modules
> separately.

That's the main task which is expected to be solved at this point, 
yes.

> 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!

Yes.  We don't maintain a stable ABI between versions, and not 
even API between mainline versions.  So preparing different 
binaries for different nginx versions is unavoidable for now.

As of now general idea is that it should be possible to compile 
module that can be loaded into an nginx binary built on a 
particular OS with particular configure arguments.  That is, you 
can prepare binaries targeting particular nginx distributions.

In the future we are likely to review and reduce number of various 
options that change nginx internal structures and hence are 
included in the signature.  This should improve compatibility 
between different builds.

> 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.

The idea of signatures and version checks is to make sure that 
a module and nginx ideas about API structures agree.  So running 
against "many signatures" looks like a wrong idea, but see above 
about reducing granularity of signatures.

We can also consider providing stable ABI in addition to API in 
stable branches, but this probably don't make a lot of sense as 
stable releases aren't happening often.

-- 
Maxim Dounin
http://nginx.org/