In checking with the project and team researching the history of the API, the API seems to be very stable.
The API is defined in the gs/psi/iapi.h file. From the time the API was introduced in 2001-03-12, there has been only one real API change, and that had to do with cleaning up the interface declarations to use void* pointers: ------------------------------------------------------------------------ r5250 | stefan | 2004-08-19 12:33:09 -0700 (Thu, 19 Aug 2004) | 14 lines Changed iapi to use a void* instead of a gs_main_instance pointer. Cleaned up warning related to function pointer signature miss-matches. DETAILS: iapi.h no longer defines a type for gs_main_instance * This will likely need to be put back in for backward compatibility. The iapi interface now uses a void * instance handle reflecting that it is an opaque type to the outside world. Note that function pointer argument miss-matches generate warnings in msvc but not in gcc. These have been fixed. ------------------------------------------------------------------------ Including changes like adding banners and changing copyright headers, there have been 19 changes in this file from 2001-03-12 till today. So the API is stable. There is just no formal commitment to the stability. - Dan James Carlson wrote: > Garrett D'Amore wrote: > >> Sorry, I guess I see a lot of apps using OpenSSL for pure crypto, rather >> than for SSL per se. >> > > True; it does happen. OpenSSL *does* have stable interfaces, but as far > as I know, the unstable ones aren't properly scoped away. Having that > done would be nice. (Perhaps have "libopenssl_naughty.so.1" with the > interfaces exposed and "libssl.so.1" as a filter exposing just the > stable ones ...) > > >> Maybe what is needed here is a ilghter weight form of contract.. one >> that doesn't require signatures or such. I'm thinking of some kind of >> "restricted" or "registered" use. The producer can say what the >> interfaces in the ARC case and give a commitment (hypothetically >> "Registered", and the Consumers are free to use it by simply filling out >> a basic form and dropping it in the case directory. The form could >> include : consuming project, bugster category, and an engineering >> contact. That would be a better shrink to fit process, while still >> achieving the goal of knowing who the consumers are. >> >> Thoughts? >> > > That's just what the existing contract mechanism is supposed to be. > It's very lightweight (just requires a couple of email messages) and > registers usage of an interface. > > I suppose if someone wanted to work on a spiffy new tool to do this, > that'd be interesting, but I think it's putting lipstick on a pig. > Contracts are -- by their very nature -- merely hacks. Proper > engineering demands stable interfaces from producers and an avoidance of > implementation details by consumers. Contracts allow us to put the > normal rules of good design in abeyance, but you can't do that too often > or for too long a time, or bad things start happening. > > In the case of openssl, it's been going on for a really long time. > > -- Dan Hain Solaris Revenue Product Engineering (RPE)
