Plugin project proposal

[Zhanna Tsitkova]

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?

Thanks,
Zhanna
________________________________________
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).


Nico
--