Massimiliano Pala escribi�:
IndeedIt is, only that if the provider is OpenSSL, then it (OpenCA::Crypto::OpenSSL) manages things that are OpenSSL objects (that is layers over pointers to X509 C structs).
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...) useUnsure about this, I am not sure I understood the implications. What is the real-world equivalent of an instance of OpenCA::Crypto::OpenSSL? A crypto provider? A crypto object (certificate, request, etc.)? Something else?
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.
I would discourage calling C methods within every module because inNo, only OpenCA::Crypto::OpenSSL does it and all OpenCA::Crypto::* modules provide the same interface to the OpenCA::X509, OpenCA::REQ, etc. classes. What I was saying is that the caller does not know in what language is a method implemented and if the C implementation provides a good interface, an additional layer is unnecessary. In other words, if you want another layer, you can have it, but you are not forced to have it and my example might be inducing Michael to think so.
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 ... ).
Anyway, the core of OpenCA and the supporting classes see nothing of this.
I think this is a misunderstanding, these classes are implementation artifacts of a particular crypto provider module, there was no suggestion of replacing OpenCA::X509 and the like, they remain essentially as they are now. These are new classes (that does not imply new OpenCA packages, they may be part of the OpenSSL package, where they logically belong).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.
I want to make a case for dealing with the internal OpenSSL things as real Perl objects and I will rest this case in one need: cleaning up after ourselves.
I have not shown it in the example, but if we have each internal openssl allocated thing mapped to one Perl object, now we can write destructors for them, I can create a new method DESTROY that will call X509_free() or whatever is needed. So we can create internal certificates when needed or store references to them in a OpenCA::X509 object and when no longer needed they will be freed correctly, for example, when that OpenCA::X509 object is destroyed.
There are other ways, of course, but they require more houskeeping and tend to leak memory. It may not be important in a CGI world, but they become critical in a mod_perl world.
For instance, instance of handling blessed references as I did, we could just keep pointers around as opaque data in the OpenCA::Crypto::OpenSSL object or create and destroy the underlying OpenSSL object everytime.
But I think my method (handling the OpenSSL things as real objects) is cleaner.
To really have the module interoperable, anyway, we should start writingI agree, that's why I did not want anything committed until we had an idea of where are we heading.
papers about strucutre and interface definition *BEFORE* writing new code.
Julio
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
