Reordering new API's that have a libctx, propq

[Tim Hudson]

On Sun, Sep 6, 2020 at 6:55 AM Richard Levitte <levitte at openssl.org> wrote:

> I'd rank the algorithm name as the most important, it really can't do
> anything of value without it.
>

It also cannot do anything without knowing which libctx to use. Look at the
implementation.
Without the libctx there is no "from-where" to specify.

This is again hitting the concept of where do things come from and what is
a default.
Once "global" disappears as such, logically everything comes from a libctx.

Your argument is basically "what" is more important than "from" or "where".
And the specific context here is where you see "from" or "where" can be
defaulted to a value so it can be deduced so it isn't (as) important in the
API.

That would basically indicate you would (applying the same pattern/rule in
a different context) change:


*int EVP_PKEY_get_int_param(EVP_PKEY *pkey, const char *key_name, int
*out);*

To the following (putting what you want as the most important rather than
from):


*int EVP_PKEY_get_int_param(char *key_name, EVP_PKEY *pkey, int *out);*

Or pushing it right to the end after the output parameter:


*int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);*

The context of where things come from is actually the most critical item in
any of the APIs we have.
Even though what you want to get from where you want to get it is in the
point of the API call you need to specify where from first as that context
sets the frame of the call.

Think of it around this way - we could have an implementation where we
remember the last key that we have used and allow you to simply indicate
you use the last key or if we didn't want the last key used to be able to
specify it via a non-NULL pointer. This isn't that unusual an API but not
something I'm suggesting we add - just trying to get the point across that
you are still thinking of global and libctx as something super special with
an exception in its handling rather than applying a general rule which is
pretty much what we use everywhere else.

And in which case where you generally don't provide a reference as there is
some default meaning for it in general and can provide a reference for that
sort of API would this make sense to you:


*int EVP_PKEY_get_int_param(char *key_name, int *out,EVP_PKEY *pkey);*

If pkey is NULL then you use the last key that you referenced, if it is not
then you use the specified pkey. For the application the specific key_name
is the most important thing (using your argument that basically states the
"what" is what counts).

I would suggest that you really would still want to place the EVP_PKEY
first - even if you had a defaulting mechanism of referring to the last key
used. Conceptually you always have to have knowledge of from-where when you
are performing a function. And that *context* is what is the most important.

Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-project/attachments/20200906/ba59b373/attachment.html>