Plugin project proposal
tsitkova at MIT.EDU
Fri Jul 16 14:50:22 EDT 2010
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.
More information about the krbdev