"Breaking compatibilty" with old apps will occur at a time :
dixit the roadmap :
"Review and revise the public API with a view to reducing complexity
(Timescale: Within one year)"
I suppose that reducing complexity will lead to some rewrites,
elimination/merging some functions...
So it will be the right time to bring some improvements such as C++
namespaces support,
or even macro renaming,
and "breaking binary compatibility" is not really a so big issue :
at a time, if something is rewritten with efficiency and simplicity in
mind, and robustness,
it has to be promoted, pushed to replace past versions.
and binary compatibility is "already" an issue : this is why there are
so many version of openssl,
too many to my mind, so that smart resources of the team are dispersed
to redo and redo again (backporting or forward porting) all the time the
same work.
Anyway, on the short term, for an app maintainer : it is a fact that a
solution to the prefixes mess can be to encapsulate openssl in a custom
lib, hiding anything from the original lib to the external world.
Pierre
Le 08/09/2014 03:52, Jakob Bohm a écrit :
And how would you do that without breaking compatibility with every
program (in C, C++ or any other language) that already uses openssl and
depends on the current API names?
Providing the API, semantics and portability of the original SSLeay
library is thesecond-most important feature of OpenSSL (right after
actually being a secure SSL/TLSimplementation when used correctly).
On 08/09/2014 01:15, Pierre DELAAGE wrote:
Hmm...
Switch strongly and definitely to C++....
Not for fancy object programming, but for more practical syntaxES for
things like this.
And I am an old C fan programmer...
Pierre Delaage
Le 08/09/2014 00:04, Kyle Hamilton a écrit :
The reason is "legacy". Eric Young was not conscious of namespace
pollution when he implemented SSLeay; since then, even after the
migration to the OpenSSL name and team, the focus has been more on
maintaining source compatibility than in creating new
interoperability opportunities.
To meet the goal of interoperability while enabling an alternate
symbolic namespace, what would you suggest?
-Kyle H
On September 7, 2014 1:30:11 PM PST, "Iñaki Baz Castillo"
<i...@aliax.net> wrote:
Hi,
RAND_xxx
CRYPTO_xxx
ERR_xxx
ENGINE_xxx
EVP_xxx
sk_xxx
X509_xxx
BIGNUM_xxx
RSA_xxx
BN_xxx
ASN1_xxx
EC_xxx
etc etc etc.
May I understand why it was decided that OpenSSL can own all the
prefixes or "namespaces" in the world? How is it possible that
OpenSSL
owns the ERR_ prefix (for example ERR_free_strings() and others)?
OpenSSL is a library. I should be able to integrate OpenSSL into my
own code and define my own prefixes without worrying about creating
conflicts with the near 200 prefixes that OpenSSL owns.
An example of a well designed C library is libuv [*], in which:
* Public API functions and structs begin with uv_.
* Private API functions begin with uv__.
* Public macros begin UV_.
That's a good design!
PS: In my project I use both openssl and libsrtp. In which of them
do
you expect the following macro is defined?:
SRTP_PROTECTION_PROFILE
[*]https://github.com/joyent/libuv/
Enjoy
Jakob
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
