Some potential plugins may not have compile-time knowledge of which codecs they will be able to support. For example, if MS or Apple decide to add an algorithm it may be available at compile-time on the developer's machine, but not at run-time if the user is on an older version of the OS. Linux has a similar issue for the kernel crypto API (the AF_ALG stuff, /proc/crypto has a list).
I'm not sure what the best way to do this would be. Loading the whole plugin may or may not be prohibitively expensive; it could be better to create a secondary shared object whose sole responsibility is to query the available plugins. The squash.ini file could still contain a list of potentially available codecs.
Some potential plugins may not have compile-time knowledge of which codecs they will be able to support. For example, if MS or Apple decide to add an algorithm it may be available at compile-time on the developer's machine, but not at run-time if the user is on an older version of the OS. Linux has a similar issue for the kernel crypto API (the
AF_ALGstuff, /proc/crypto has a list).I'm not sure what the best way to do this would be. Loading the whole plugin may or may not be prohibitively expensive; it could be better to create a secondary shared object whose sole responsibility is to query the available plugins. The squash.ini file could still contain a list of potentially available codecs.