<div dir="ltr"><div dir="ltr">Dear Matt,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2020 at 12:48 PM Matt Caswell <<a href="mailto:matt@openssl.org">matt@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 14/02/2020 09:41, Dmitry Belyavsky wrote:<br>
> Hello,<br>
> <br>
> On Fri, Feb 14, 2020 at 5:30 AM Dr Paul Dale <<a href="mailto:paul.dale@oracle.com" target="_blank">paul.dale@oracle.com</a><br>
> <mailto:<a href="mailto:paul.dale@oracle.com" target="_blank">paul.dale@oracle.com</a>>> wrote:<br>
> <br>
>     There is some pushback against the deprecations going on in various PRs.<br>
> <br>
>     The plan has always been to deprecate engines in 3.0 and removing<br>
>     support for them 5+ years later.  Originally, the path was to have<br>
>     included an engine provider that could load engines and make them<br>
>     appear to be a provider.  After a fair amount of investigation, this<br>
>     was deemed to be too difficult in the 3.0 time frame.<br>
> <br>
>     Do we still want to deprecate engines in 3.0?<br>
>     Should we defer until 4.0 instead?<br>
> <br>
> <br>
> I think we should delay the deprecation of engine stuff to 4.0.<br>
> Personally I don't have sense of stability of provider API.<br>
<br>
Well - it isn't stable *right now*. Its in development. But moving<br>
forward the provider model *is* the way we intend to go. By the time of<br>
the 3.0 release the provider stuff had better be stable, otherwise we've<br>
gone wrong.<br></blockquote><div><br></div><div>Totally agree. Though the conversion between engines and providers is not as straightforward as I want, so I prefer to wait for some time. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
As has been pointed out many times. Deprecation does not mean removal<br>
(yet). Its just a signal that at some later time we will remove it.<br></blockquote><div><br></div><div>Sure. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
And the 3.0 is the right time to signal that. We don't want to hold on<br>
the "legacy" codepaths for any longer than we have to. They were only<br>
ever originally intended to be temporary, and to be removed before 3.0<br>
got released. However it now looks like they will live beyond the 3.0<br>
release. They should not live for any longer than absolutely necessary.<br></blockquote><div><br></div><div>Hmmm. Not sure here. I remember the introduction of EVP_PKEY_ameth/pmeth currently moving to providers. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">>     The main benefits seem to boil down to continuing to support<br>
>     existing engines vs removing the legacy code paths and switching to<br>
>     the provider model.<br></blockquote><div><br></div><div>It's worth explaining the benefits to engine authors :)</div><div>I understand the benefits of OpenSSL as a product and still now don't have</div><div>a firm understanding of benefits for the surrounding ecosystem. Though I did not dive into the providers deeply.</div><div><br></div><div>I still have a suspicion that we will not have function signatures for callbacks in providers.</div><div>Do we? If don't, we'll have a set of errors implementing it.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> For me, both as open-source and commercial engine developer seems<br>
> reasonable to delay conversion from engines to providers at least until<br>
> 3.0.0 feature freeze happens.<br>
<br>
That's a perfectly reasonable strategy. But this decision is independent<br>
of whether we deprecate the ENGINE APIs in 3.0 or not. It would be<br>
perfectly ok for people to continue to *use* engines in 3.0 even though<br>
they are deprecated.<br></blockquote><div><br></div><div>Sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But some features I'm interested in imply engine model (and it will be<br>
> great if somebody else could look at PR 10904 to avoid it when possible).<br>
<br>
If there are gaps then we need to plug them. The provider model should<br>
be able to do everything that you can do now in ENGINEs.<br></blockquote><div><br></div><div>Totally agree. </div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">SY, Dmitry Belyavsky</div></div>