Asynchronous operation and krb5 dependencies

ghudson@MIT.EDU ghudson at MIT.EDU
Thu Jun 2 16:20:34 EDT 2011


We are working on making it possible for KDC plugins to operate
asynchronously.  To do this, we need to give them access to the KDC's
main loop.

Our current design plans for this would involve making the KDC
dependent on two libraries: first, libevent, which is pretty widely
packaged (it's in Solaris, NetBSD, most Linux distributions, etc.);
and second, a new wrapper called libverto.

The purpose of the wrapper is to allow runtime selection of an event
loop implementation, to solve the problem of libraries exposing
asynchronous functionality in an event-loop-neutral manner.  For
instance, an application using glib could create a vtable of wrapper
functions around g_main_*() and instruct libverto to use those
functions instead of libevent's functions.  libverto is expected to be
an independent project hosted on fedoraproject, and should be a small
piece of code.

This wrapper isn't strictly a requirement for the KDC today since it's
not a library, but at some point we plan to make a KDC library, which
would create a problem if KDC plugins are coded directly against
libevent.

My questions are directed at people who build MIT krb5 (as part of OS
distributions or otherwise):

1. Is a hard dependency on libevent a problem for you?  I'm not sure
how we could avoid this, but I'd at least like to know the size of the
problem.

2. Is a hard dependency around a small new independent library a
problem for you?  libverto is expected to be small enough that we
could bundle it under util/ as an optional component, like we do
com_err and ss; before committing to doing that, I'd like to know if
it would help anyone to bundle libverto if we're not bundling libevent
as well.



More information about the krbdev mailing list