In order to offer one server and many modules instead of one large server, one needs to redesign the signalling system to work dynamically.

Since we want to have two sides to our system: a CGI that directly communicates with Apache and the actual Snap! Server to which the CGI connects to to get the HTML or other result to be sent back to Apache.

This means the Snap! Server is started once and serves numerous times without having to rebuild all the event tables on each access (nor the connection to the Cassandra system. TBD... can we really just duplicate the Unix socket identifier?) This is actually not the case. The plugins that get loaded are defined on a per website basis so they get loaded only after we create the child process. Also trying to load the plugins once and reuse them many times could generate many unwanted side effects (i.e. static variables that get shared between instances.) So at this point the plugins get reloaded on each hit although they should already be in memory because the kernel is likely to keep them there and also share them between instances.

The result is that the use of a dynamic signal system isn't that bad. It changes the mechanism though.

1) Use signal system (boost::signals2)

2) On initialization plugins auto-register themselves as listeners using a factory

3) Emit an event by calling the corresponding signal functions

The Boost signal system implies that plugins know what signal they want to listen to at compile time. This is good to make sure that the parameters passed in the signals are properly typed. However, while loading the plugins, no order is respected. This means we cannot register all the signals because at the time plugin A is loaded, it cannot connect to plugin B signal if B wasn't loaded yet.

The factory of each plugin is built using a simple macro that instantiates an object allocating the plugin with the new operator and registering the plugin initialization signal (named bootstrap). The initialization code will then take over and connect all the other signals as required.

Since we're running with a server that is started once and reused many times, this method is a little slower than the full static event system but it still works very quickly since it doesn't need to re-initialize all the event stacks every time the Apache CGI connects to it. See comment in the other paragraph that was striked out...