I was thinking OSSL_LIBCTX?

> On 24 Jul 2020, at 5:38 pm, Dr. Matthias St. Pierre 
> <matthias.st.pie...@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.
> OTOH, it would be ok for me if we would make an exception for EVP_MAC and 
> 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-boun...@openssl.org> On Behalf Of 
>> Richard Levitte
>> Sent: Friday, July 24, 2020 8:34 AM
>> To: openssl-project@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...

Reply via email to