This adds support for multiple named session pools.
I figured that people in the past repeatedly wanted to have different values for our "global" options (e.g. disable_scripts) per print job, or rather likely per template. As this goes against my original idea of keeping "initialization work" strictly to the initialization (SpawnSession) and keep the amount of work per print job to a minimum, I'm inclined to point people to the existing possibility of launching multiple ChromicPDF instances with different configs (think: print queues). However, launching a separate ChromicPDF supervisor means launching additional OS processes of chromium, which seems wasteful. At this point I realized that we're lacking a middle layer in the session pool, i.e. differently configured sessions. This PR fixes that by introducing named session pools that can have pool-specific configs.
This adds support for multiple named session pools.
I figured that people in the past repeatedly wanted to have different values for our "global" options (e.g.
disable_scripts) per print job, or rather likely per template. As this goes against my original idea of keeping "initialization work" strictly to the initialization (SpawnSession) and keep the amount of work per print job to a minimum, I'm inclined to point people to the existing possibility of launching multiple ChromicPDF instances with different configs (think: print queues). However, launching a separate ChromicPDF supervisor means launching additional OS processes of chromium, which seems wasteful. At this point I realized that we're lacking a middle layer in the session pool, i.e. differently configured sessions. This PR fixes that by introducing named session pools that can have pool-specific configs.API
Docs