Subject: [kitten] Simplified and async API try #2

From: Nico Williams <[email-masked]>
Date: Sat, 23 Feb 2013 18:38:23 -0600

> https://raw.github.com/nicowilliams/kitten/master/gss-step-ctx.txt

I've come up with an idea regarding event loops and how to pass them
in: just abstract them.  Indicate an event loop type and pass in a
void *, as well as optionally also a void * for the module
implementing the event loop and optionally also a pointer to a
dlsym()-/GetProcAddress()-like function.  Specify several event loop
types, recommend/require one to be implemented.

Now we might look at this and decide that we don't want to have any
more than one event loop type (say, verto).  Apps that don't use it
can implement it as a shim on top of whatever they do use.  I'd like
this.

Nico
--

---

From: "Stefan (metze) Metzmacher" <[email-masked]>
Date: Mon, 25 Feb 2013 15:29:15 +0100

> can implement it as a shim on top of whatever they do use.  I'd like

I think it's fine to have just a few, one or event no event loop
type standardized, but indicate that implementations may want to
offer more. Typically the implementation should have one function
to specify an instance of its native event loop implementation.

So one out of this:
OM_uint32 gss_set_context_virto_ctx(OM_uint32 *minor_status,
                                    gss_ctx_id_t context,
				    struct verto_ctx *ctx);
OM_uint32 gss_set_context_tevent_context(OM_uint32 *minor_status,
                                         gss_ctx_id_t context,
				         struct tevent_context *ctx);
OM_uint32 gss_set_context_glib_loop(OM_uint32 *minor_status,
                                    gss_ctx_id_t context,
				    GMainContext *mc, GMainLoop *ml);
OM_uint32 gss_set_context_libevent_base(OM_uint32 *minor_status,
                                        gss_ctx_id_t context,
                                        struct event_base *ebase);

I think if the application wants to share an event loop with the
gss libraries, it should be indicated explicitly. The application
should may use something like verto_convert_tevent().
Otherwise the gss libraries should use threads or don't offer the
functionality.

metze

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 25 Feb 2013 07:27:25 -0800

> Otherwise the gss libraries should use threads or don't offer the

how would the application get notified when GSS framework have a new token/new step is needed in this case since the step function doesn't take a callback.

Love

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 10:38:31 -0600

> to specify an instance of its native event loop implementation.

But we can't really standardize event loop APIs here.  With the
possible exception of verto I doubt any of them would give us (the
IETF) change control.  Conversely, I don't think we can have normative
references to external definitions of event loop APIs without some SDO
behind them that the IETF can recognize.

> So one out of this:

These explicitly refer to C types from external event loop APIs, and I
don't see how we manage this in a standard (see above).  To be sure,
we don't need a standard for this either: we can just implement this
in Heimdal and MIT and leave it at that.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 25 Feb 2013 10:44:54 -0600

On Mon, Feb 25, 2013 at 9:27 AM, Love Hörnquist Åstrand <[email-masked]> wrote:
> how would the application get notified when GSS framework have a new
> token/new step is needed in this case since the step function doesn't take a
> callback.

There's a separate function for setting a callback (or other
signalling mechanism).