What about crypto lib to be loaded dynamically, i.e. xmlsec core to have "plugin architecture"?

Aleksey you now better what is necessary to be defined for plugin.

About packages ... every os has different name/structure convention. On some os-es package include all (executables, libraries, include files, docs). On other packages are split on binaries and include files. "make install" should install all in $(DESTDIR). How to create/What to include in a package responsible is package maintainer not developer.


May be we should have some wrappers as example for certificate:
===========================================
typedef struct xmlSecCert_s {
int crypto_id; ....
union {
....
#ifdef HAVE_NSS
CERTCertificate* nss;
#endif
#ifdef HAVE_OPENSSL
X509* ssl;
#endif
....
} cert;
....
} xmlSecCert
===========================================


and plugin structure

===========================================
typedef structure xmlSecX509_s {
....
xmlSecCert* (*get_key_cert) (xmlSecKeyDataPtr data);
int (*adopt_key_cert) (xmlSecKeyDataPtr data, xmlSecCert* cert);
....
} xmlSecX509;
===========================================




Aleksey Sanin wrote:

Hi, All!

I would like to make some changes to the current xmlsec build
system. Currently we have followng situation:

*nix, Mac, etc. (autogen/automake/autoconf):
   We build all possible xmlsec-<crypto> libraries but only
   one xmlsec  command line tool linked against "default"
   crypto library
   RPMs are build as follows:
        - xmlsec, xmlsec-devel: core xmlsec and default
        xmlsec-<crypto> libraries, command line tool linked
        against the default crypto libs. For my RPMs, default
        crypto means "openssl".
        - xmlsec-nss, xmlsec-nss-devel: libs for xmlsec-nss,
        no executable
Windows:
   We build libraries and executable for the default crypto only.

I would like to change these and *aways* build all the xmlsec-<crypto>
libraries and xmlsec command line tools linked with each of
xmlsec-<crypto> libraries:

*nix, Mac, etc. (autogen/automake/autoconf):
   As before build all libraries (of course, user can disable
   some libraries from ./configure script). Build xmlsec1-openssl,
   xmlsec1-nss, xmlsec1-gnutls, etc. command line tools and
   later make a symbolic link "xmlsec1"-->"xmlsec1-<default crypto>".
   Probably there would be an option "--default-crypto" for
   ./configure script too.
   Also, RPMs would now have following structure:
       - xmlsec, xmlsec-devel: core xmlsec libraries, no executables
       - xmlsec-openssl, xmlsec-openssl-devel: openssl libs and
       executable
       - xmlsec-nss, xmlsec-nss-devel: nss libs and executable

Windows:
Build libraries and command line tools for all crypto libraries listed
in comma separated list in option "crypto" for the configure.js script.
After that, copy the "xmlsec-<default-crypto>.exe" to "xmlsec.exe"
where <default-crypto> is the first item in the "crypto" list (do we need
a separate "default-crypto" option?).


I would appreciate if John, Igor and everyone else interested can review
this plan and send your comments/suggestions. I am going to make these
changes next week on MS Crypto branch so we would have some bake time.

Thanks,
Aleksey



_______________________________________________
xmlsec mailing list
[EMAIL PROTECTED]
http://www.aleksey.com/mailman/listinfo/xmlsec





_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec

Reply via email to