Darren J Moffat wrote:
>
> The reason it was done for OpenSSL was because it was known not to
> have a stable API or ABI at the time. That has changed over time and
> the massive number of ARC contracts (more than any other case in
> history and I'm sure there as some missing) has become a total
> paperwork burned with no pay off.
>
> That is going to change very very soon as OpenSSL is quickly
> approaching a 1.0.0 release (it is currently in Beta 2). At the point
> it reaches 1.0.0 we plan to no longer use contracts.
>
> So given the above please don't use OpenSSL as a precedent setting
> case - unless it is to demonstrate that for unmodified upstream
> community FOSS the contract system is unworkable in some cases.
>
But as we've seen recently, openssl's interface breakage across
consolidation boundaries can cause pain and suffering. While contracts
a pain in the neck, they *should* have the effect of helping project
teams track usage and figure out who needs to be worked with when
updating versions.
In the case of OpenSSL I think it should do something else --
applications using OpenSSL that are developed *internally* really
shouldn't be using OpenSSL. We should be directing such applications to
PKCS#11 which is a standard and stable API, and plays much better with
our encryption framework.
I hope when the OpenSSL 1.0 is released, it also means that they will
give something beyond lip service to API and ABI stability. That would
be something new. :-)
Now maybe the interface stability considerations aren't a big deal here
for ghostscript. I'd at least like the question answered -- if the
interfaces are generally stable, then I have no problem with a Volatile
or Uncommitted binding. If they are so unstable as to limit what we can
do with them (such as upgrading to newer releases of the upstream), then
I'd recommend a Contracted interface just to help us understand the uses
of the API. (I suspect far fewer applications use ghostscript than use
OpenSSL, so the concerns are probably much less severe here.)
-- Garrett
