Plugin project proposal
tsitkova at MIT.EDU
Thu Jul 15 16:57:54 EDT 2010
The assumption here was that krb5 contexts are usually created at the start-up, are long-living and there are very few contexts created. So, it thought to be a good idea for all heavy work to be done at the beginning. In this case the run-time performance, i.e. what happens after the start-up, benefits from this approach.
Yes, I understand that for many environments it is undesirable to load all libraries up-front and I accept that this should be taken into consideration. It definitely can be done.
On the other hand there are consumers who would prefer to load all what they need and have the free ride at the run time, right?
From: Nicolas Williams [Nicolas.Williams at oracle.com]
Sent: Thursday, July 15, 2010 1:43 PM
To: Zhanna Tsitkova
Cc: krbdev at mit.edu
Subject: Re: Plugin project proposal
On Thu, Jul 15, 2010 at 12:59:01PM -0400, Zhanna Tsitkova wrote:
> The main participants in the new architecture are:
> Plugin related configuration and registration happen at run time,
> during the krb5 context creation. At this time PM registers all
At krb5 context creation time?! What if a plugin isn't needed? Must
the caller still load it?
Besides being a disaster for performance, this is also inviting DLL
hell (I'm thinking of OpenSSL getting loaded unnecessarily by
unnecessarily loading the PKINIT pre-auth plugin).
More information about the krbdev