Hi there,

On Thu, 20 Jan 2000, Richard Levitte - VMS Whacker wrote:

> appro> > as argument instead of a
> appro> > 'void *' (a non-anonymous variant 4).
> appro> But it breaks *source* code compatibility and old users gonna
> appro> get (really) frustrated.
> 
> That is true, but on the other hand, there have been many discussions
> that seem to point to a need to break source compatibility.  That or
> doing a triple bendover at some point...  And as far as I understand,
> source compatibility has already been broken.
> 
> Here's another Decision for us: clean up and break source
> compatibility on some points or work really hard at maintaining source
> compatibility and building something that has potential of being quite
> messy.

Well it has already "realised its potential" in that respect. :-) I've
been a pretty vocal advocate of making the changes that should be made to
get OpenSSL a lot more solid now, rather than prolonging the game of
"macro twister" that seems to be the "backwards compatible way forward" of
choice. I won't lambast y'all with that again ... some people's priority
is a clean library and API that operates consistently and is a pleasure to
code with, some people prefer to benefit from improvements and features
without having to change their own code to work with newer versions (or at
least want to be forced to do so by compiler failures rather than a
README). It's up to us all to decide (particularly the core developers).

Whatever the outcome of that debate - if we *do* agree that "clean up and
break source compatibility" is the way to go, can we start to identify now
the areas that could most benefit from the liberation this amnesty would
give so that we can (hopefully) rejig the most desperate parts in one go.
This would hopefully mean that bringing dependant code inline with 0.9.5
(or whichever version) would be the only major "API resuscitation"
required rather than spreading the compatibility-breaking changes over a
number of releases? (NB: by API I'm referring not just to the functions
and type declarations, but the defined behaviour of the API calls also).

It would be no surprise to anyone that I'd want to pitch in a vote for
some reference counting cleanup, but a few other similar "does it *have*
to be this way?" issues have cropped up of late (memory management
callbacks and debugging is one that springs to mind) and there are
probably quite a few a lot older too ... I think we should start building
a list of the most wanted fixes should source-compatibility be deemed
breakable at any stage.

Perhaps ... "What would you like to change today?"

:-)

Best regards,
Geoff


----------------------------------------------------------------------
Geoff Thorpe                                    Email: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europe    http://www.int.c2.net
----------------------------------------------------------------------
"It is wrong always, everywhere, and for everyone, to believe
anything upon insufficient evidence." - William James


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to