Bear Giles wrote: > Remember that there are actually two independent pieces of code here - > a "tab A" independent shared library and a "slot B" library that loads > it. The latter can provide convenience wrappers to functions in the > former, avoiding the need to duplicate code in the independent part.
I think it might well be a case of more than just convenience. Tab A will be aware of the specifics of the back-end storage that will allow it to provide performance beyond what a generic convenience function could hope to. Take the difference between the generic algorithms in the C++ Standard Template Library and their corresponding container-specific member functions as an example. The algorithm find, knowing nothing about the innards of the container it is being asked to search through, is forced to iterate through its every item, resulting in linear complexity. A given container member function find, on the other hand, will be aware of the fact that it internally uses a red-black tree to hold data, and is thus able to offer the equivalent functionality in mere logarithmic complexity. (This example was "borrowed" from Meyers' "Effective STL" item 44.) > We all agree that the db API part needs to fall somewhere between > generic data store and full cryptoki implementation. I just wanted > to point out that it's actually two pieces, and the interface provided > to the users will almost certainly be far more PKI-aware than the > interface provided by the independent part alone. I think this is contradicted by your response below. First our API should fall somewhere between a generic Database and Cryptoki and later on the two are completely independent? I hope my responses earlier today have made it clear where I stand on the issue. > > From a storage > > point of view, a smart card (or an nCipher box!) can very well be > > viewed as a limited database. That it also has functionality like > > symmetric ciphers, digests and pkc is beside the point and outside > > this discussion. > > Precisely. Best regards, //oscar ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
