[16844] in Kerberos_V5_Development
Re: Asynchronous operation and krb5 dependencies
daemon@ATHENA.MIT.EDU (Nico Williams)
Mon Jun 6 06:46:12 2011
MIME-Version: 1.0
In-Reply-To: <1307126252.3399.9.camel@localhost>
Date: Mon, 6 Jun 2011 05:46:07 -0500
Message-ID: <BANLkTimQmiJ+jH15+_RobwNaD8u7EL08wA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Cc: "krbdev@mit.edu" <krbdev@mit.edu>
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
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 eventloop 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 wherethere's no obvious way to reference any particular context due to thelack of a krb5_context-like argument?)
Nico--
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
