API renaming

[Richard Levitte]

Why?  Just because some of us used such variable names when there was
a need to distinguish it from other contexts that are sometimes
juggled with at the time time?

(and yeah, I've made that a habit...  but why that would determine the
type name, I cannot understand)

Cheers,
Richard

On Fri, 24 Jul 2020 09:42:59 +0200,
SHANE LONTIS wrote:
> 
> I was thinking OSSL_LIBCTX?
> 
> > On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> > 
> > I like the OSSL_ prefix for new APIs as proposed by Richard. And I agree with Shane
> > that we should go for a single prefix and not have two alternatives. Existing prefixes
> > for things like feature macros should remain as they are, but if the OSSL_ prefix is
> > our choice for the future, we should start using it consistently for _all_ new APIs in 3.0.
> > And not make it a random choice (pun intended) depending on whether the API went
> > into master early or late. So my favorite choice is a consistent renaming, i.e.
> > 
> > 	OSSL_MAC, OSSL_KDF, OSSL_RAND, OSSL_CTX, ...
> > 
> > OTOH, it would be ok for me if we would make an exception for EVP_MAC and EVP_KDF,
> > because they have a long EVP history, as Matt pointed out. But using the EVP_ prefix
> > for the new RAND interface never made sense to me.
> > 
> > What bothers me about OPENSSL_CTX in particular is the fact that it is a mixture of
> > a non-abbreviated and an abbreviated word. IMHO it should be either OSSL_CTX or
> > OPENSSL_CONTEXT, and the former is obviously preferrable for its length.
> > 
> > Matthias
> > 
> > 
> >> -----Original Message-----
> >> From: openssl-project <openssl-project-bounces at openssl.org> On Behalf Of Richard Levitte
> >> Sent: Friday, July 24, 2020 8:34 AM
> >> To: openssl-project at openssl.org
> >> Subject: Re: API renaming
> >> 
> >> I'm fine with that, really.
> >> 
> >> I have a preference for OSSL_, but if we look through the source,
> >> there's reason for either.  So far, we've majorly used OPENSSL_ for
> >> things like feature macros (disabling macros, really), environment
> >> variables, that sort of thing, while OSSL_ has become the primary
> >> choice for new APIs ("less klunky", I think the judgement was in that
> >> past discussion I keep referring to).
> >> 
> >> And yeah, I hear you from all the way around the planet, there are
> >> some recent name choice that were made that give pause and are
> >> arguably a mistake in this regard.  EVP_MAC and EVP_KDF could have
> >> been OSSL_MAC and OSSL_KDF.  OPENSSL_CTX could have been OSSL_CTX.
> >> I have no problem recognising that.  But, they are there, even though
> >> only in master (*).  This is question of what we do going forward (a
> >> yet unmerged PR with a new API is as good a target as any).
> >> 
> >> Cheers,
> >> Richard
> >> 
> >> (*) I'm not sure I see master as something untouchable in this regard,
> >> as the development is still not frozen (alpha), so I for one could
> >> easily see a rename fest happening, should we decide for it.  That
> >> must happen before we enter the beta phase, though...
> >> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/