Plugin project proposal

[Zhanna Tsitkova]

Thank you all for the valuable input and lively discussion.

I would like to summarize the comments made on the list to proceed to  
the next version of the proposal.

1. One should avoid  heavy-lifting in krb5 contexts as they may be  
frequently created and short-living;
2. It is undesirable to do load all plugins up-front, during the start- 
up. The approach per-need is preferred in many cases.
3. The type-safety of plugin interfaces is important. However it comes  
with the price of making code less readable and, perhaps, negatively  
effects the performance.

As Russ said "a major goal of the plugin architecture should be to try  
to make the code internals more transparent and obvious.  One of the  
things that I struggle with right now in the MIT Kerberos code base is  
that it can be extremely difficult to trace through code and figure  
out where things are actually being done." It is hard to disagree with  
this statement. Simplicity is good. But, unfortunately, some degree of  
the complexity is also unavoidable. And my philosophy here is that we  
should move as much of this complexity into the plugin management  
mechanism so that the plugin writers and consumers would enjoy the  
simplicity and transparency of their tasks.


We will review the design and hopefully post the updates next week.

Thanks again,
Zhanna