Julio S�nchez wrote:
I don't understand why you want this ::OpenSSL::Lib. I think my example was misleading, you can have Perl methods and C methods in the same class.. I'll try to provide a cleaner version that shows this by providing a Perl constructor for ::OpenSSL::X509.
Well, I do not like the idea of having the OpenSSL in the middle. Indeed I would like to have something dynamically loaded upon the creation of a new instance of the OpenCA::Crypto class.
I think the best would be that different classes (X509, REQ, etc...) use
their own instance of the class. Here it is an example:
x509 = new OpenCA::X509( "OpenCA::Crypto::OpenSSL" );
and within the OpenCA::X509 module:
sub new {
...
...
crypto = new $1(); /* I am not sure, but it is an
example */
}
This will enable x509 to use the methods in the dynamically loaded module
(OpenCA::Crypto::OpenSSL) directly, so we do not need to instantiate a
cryptoShell before initializing a new crypto object.
The concept is: we keep the actual OpenCA::X509, OpenCA::REQ, etc... but
we do not need the cryptoShell variable as each class will use their
crypto dynamically loaded module.
I would discourage calling C methods within every module because in
this way code will not be re-usable (the X509, REQ, etc... cannot remain
the same changing the crypto library if we directly call the lib from
them ... ).
For the Lib tool, I guess all the functionalities needed by the OpenCA::
modules about crypto should be in the Crypto module itself and defined
in the interface, while additional tools should be implemented in the
OpenCA::Tools.
Also, last note, the OpenCA::Crypto::XXXXX module should not call the
"upper-level" modules (i.e. X509, REQ, Tools, etc... ) because we should
keep layers independent one from another in the down->up vision.
So I would reject the OpenCA::OpenSSL::X509, OpenCA::OpenSSL::REQ, etc..
structure and instead I would build a new OpenCA::Crypto module (the
loader, but this could simply be empty) and a new OpenCA::Crypto::OpenSSL
one.
To really have the module interoperable, anyway, we should start writing
papers about strucutre and interface definition *BEFORE* writing new code.
Let me know.
--
C'you,
Massimiliano Pala
P.S.: I am moving the subject to the openca-devel list too because I think
it is mature for a more "large" audience.
--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.org Tel.: +39 (0)59 270 094
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365
smime.p7s
Description: S/MIME Cryptographic Signature
