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