> > One classic approach is to have all lookup functions return a > > list of unique keys. The caller then requests each object individually > > via a lookup that guarantees uniqueness. Uniqueness is easy to guarantee > > on any hashed or relational store - make it the primary key! > > An earlier attempt used a hash of the entire certificate which, if it > isn't unique would be the least of your worries...
Issuer and subject number should also be unique, and it's a common search pattern. I don't think anyone searches on the hash of the entire certificate. > In any case the problem with returning a list is the amount of work that > might be involved in satisfying a huge query. If it were simply a matter > of space then returning keys would indeed be OK. It's not just concern about memory requirements. This is a very common problem (think Enterprise Java Beans (EJB)), and it makes sense to build on earlier work. > That's the kind of thing I looked at when I started on a revision ages > ago. One problem with that is how to add additional lookup methods when > they are needed without breaking existing code. I got a key db about 80% implemented on Monday... then got hit with a nasty virus making the rounds. Maybe I'll be able to finish by this weekend - at least I can no longer toast marshmellows on my forehead. But support for additional lookup methods isn't a problem. You just have a version number in the plug-in and the loader links in an "unsupported operation" function if the versions don't match. The caller should check the error code... but it should be doing that anyway. :-) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
