[16994] in Kerberos_V5_Development
Re: : Why are we using libverto again
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Jul 7 14:07:21 2011
MIME-Version: 1.0
In-Reply-To: <1310060202.2694.67.camel@t410>
Date: Thu, 7 Jul 2011 13:07:17 -0500
Message-ID: <CAK3OfOg+FsriShPYkgvxT6cRmW_DZbCqFXACB-jtSySU2-7WQg@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Greg Hudson <ghudson@mit.edu>
Cc: Sam Hartman <hartmans@mit.edu>, "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, Jul 7, 2011 at 12:36 PM, Greg Hudson <ghudson@mit.edu> wrote:> On Thu, 2011-07-07 at 10:44 -0400, Sam Hartman wrote:>> Now, for the KDC today, we could just use a specific event library and>> gain significant complexity savings.>> The reason I favor an intermediary is that the event loop will be part> of the API for kdcpreauth plugins (and probably KDB and authdata plugins> in the future). Picking an event loop now carries costs not just for a> future libkdc but also a plugin interface transition cost.
The same sort of thing could apply to GSS mechanism implementationswith async GSS extensions. Particularly when one wants to use asingle event loop that is outside the control of the mechglue, muchless the mechanisms. The alternative is every mechanism (or pre-authplugin) starts a thread to run its own event loop, but then yourequire threading support.
That's the value I see in libverto.
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
