[16846] in Kerberos_V5_Development
Re: Asynchronous operation and krb5 dependencies
daemon@ATHENA.MIT.EDU (Nathaniel McCallum)
Mon Jun 6 08:50:53 2011
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Mon, 06 Jun 2011 08:50:46 -0400
In-Reply-To: <BANLkTimQmiJ+jH15+_RobwNaD8u7EL08wA@mail.gmail.com>
Message-ID: <1307364648.2174.1.camel@localhost>
Mime-Version: 1.0
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Mon, 2011-06-06 at 05:46 -0500, Nico Williams wrote:
> On Fri, Jun 3, 2011 at 1:37 PM, Nathaniel McCallum
> <npmccallum@redhat.com> wrote:
> > This is not a DLL hell problem. The problem is that exposing a
> > particular event loop in your public api means that at run time you are
> > locked into using that event loop (aside from using hacks like
> > LD_PRELOAD). This means that your library is incompatible with every
> > application that chooses another event loop.
> >
> > The solution is simple. Your average library requires only a small
> > subset of what each event loop provides. If you can provide a *run-time*
> > wrapper which provides this small subset, you can make public api's
> > asynchronous without having to choose an event loop for your
> > applications. This has nothing to do with DLL hell, unless you know of
> > a way to do lazy symbol loading during exec()...
>
> I think the solution is simple: let the highest layer provide an event
> loop handle in the form of a set of libevent-like (same prototypes,
> basically) function pointers and even base pointer.
>
> (Well, but then, how do you deal with APIs like the GSS-API where
> there's no obvious way to reference any particular context due to the
> lack of a krb5_context-like argument?)
This is exactly what we are doing, with a wrapper library.
GSS-API is largely unrelated (for now) since it will just have to
continue using the synchronous apis. When GSS-API becomes async, it can
use libverto.
Nathaniel
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
