[16010] in Kerberos_V5_Development
Re: Plugin project proposal
daemon@ATHENA.MIT.EDU (Zhanna Tsitkova)
Fri Jul 16 14:50:33 2010
Message-Id: <752FD809-04C9-47C4-9677-525C1BFADFEC@mit.edu>
From: Zhanna Tsitkova <tsitkova@mit.edu>
To: Zhanna Tsitkova <tsitkova@mit.edu>
In-Reply-To: <0B067FD4-024D-41A6-889F-23687B912975@mit.edu>
Mime-Version: 1.0 (Apple Message framework v930.3)
Date: Fri, 16 Jul 2010 14:50:22 -0400
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
