Massimiliano Pala escribi�:
I was thinking that some crypto provider might need some complex initialization or need state or need to have its access serialized, etc.and having one per OpenCA object might create problems.Julio S�nchez wrote: [...]Unsure 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?
A crypto provider...
I was thinking of hardware-based providers, but I am not really on firm ground here.
If you mean OpenCA::Crypto::OpenSSL::X509 and the like, yes they are internal to the module that provides crypto with the help of OpenSSL (I may have been dropping a Crypto:: here and there, I am afraid). They are just thin layers over the things that libcrypto manages and they are mostly written in C in an .xs file.No, only OpenCA::Crypto::OpenSSL does it and all OpenCA::Crypto::*[...]it and my example might be inducing Michael to think so.Ok, I was misunderstanding. So the Crypto::* are internals to the general crypto interface, nothing to do with actual modules, right ?
If you mean OpenCA::Crypto::CryptoAPI or something like that, it would be module that implemented crypto by calling the CryptoAPI , etc.
In the latter case, we may have a switch thing that processes all requests, does some common processing and dispatches the rest to the different providers (DBI does this and the providers would implement some common interface that users of the switch would never see). That is, their methods would be invisible.
O we may have all providers as subclasses of a class that defines the interface and common methods that are reused by inheritance. In this case, some of its methods would be visible.
In a traditional language, the first way would have the advantage of allowing run-time determination of which provider to use. But in an interpreted, run-time extensible, language like Perl, the second way would let you do it too.
So it amounts to a matter of taste. Opinions?
Again, I think I was not precise in the naming. They would rather have names like OpenCA::Crypto::OpenSSL::X509 and the like.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).
Why are them internals to the Crypto:: and not to the specific OpenSSL:: ?
The crypto then exports a single interface or an interface for each of
its internals ?
Not sure.
Can you start writing a sort of documentation (lyx, openoffice, ... as
you wish) about this structure ?
I will. 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
