From: Bear Giles <[EMAIL PROTECTED]>
bear> > That, or have the plug-ins keep a very sharp eye on the version of the
bear> > loading OpenSSL to avoid version clashes (something we do with engines
bear> > today, sadly).
bear>
bear> Other way around - the framework has to pay close attention to the
bear> version of the plugin. I think the only dynamic library system that
bear> avoids versioning is Microsoft DLLs, but that may just be a Unix
bear> campfire horror story.
I think you misunderstand. On Unix as well as on VMS and others, it's
often possible to upgrade a shareable library to a newer version
without breaking the programs using it. This requires the API to stay
the same except for added functions, and for types and structures to
never change (except for adding new types and new structures). If
those two conditions aren't met, you must have one end checking that
the other is of a known version. This is what we have with the ENGINE
framework today, a "dynamic" engine can (should, actually) have a
global entry to a function that will check that the call libcrypto's
version is the same as the dynamic engine was compiled against.
I know of other shared libraries that have things set in stone so an
upgrade doesn't disturb anything. The one I've been playing with
mostly lately is nCipher's CHIL library.
--
Richard Levitte \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47
\ SWEDEN \ or +46-733-72 88 11
Procurator Odiosus Ex Infernis -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, GemPlus: http://www.gemplus.com/
Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
