I can do it in a couple days but first I would like to ask a question: does anyone have a need in such an improvement? Any use cases for it?
One case is the xmlsec tool. Instead of having xmlsec1-nss, etc., have only xmlsec1 and select the engine at the command line. The xmlsec tool is a model application for the xmlsec library-- things we can surmise from this tool likely apply to any binary application using the library.
Another case is any new library that will depend on libxmlsec. Currently, the author of such software might be tempted to propagate the compile-time xmlsec option and make libfoo-openssl, libfoo-nss, etc., versions of his library. (Now if his library had it's own compile time options, then you can see how things get ugly. We get libfoo-a-openssl, libfoo-b-nss, etc. An then another new library depends on libfoo... and so on.) It would be better if he could just distribute one version of his library and let the xmlsec crypto enigne be selected by the user of the library or on-site.
I don't know anything about the complexity of dlopen or security issues of using plugins. I'm only commenting on the benefits of deferring crypto engine selection.
Regards, -John
-- http:// if le.o /
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
