Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Tue, Aug 18, 2009 at 12:13:28AM +0200, Leif Johansson wrote:
> > I think Leif has expressed interest in (3) before.
> 
> That was exporting unfinished contexts actually - slightly different.

Oh yes, that too (that's trivial, of course, though exporting non-fully
established contexts has to be allowed to fail).

> > >    4. error message reporting
> > >    5. asynchronous calls
> >
> > The last 2 are generally required for use by modern applications.
> 
> hmm, is asynchronous calls related to exportable contexts perhaps...?

No.  Think of how gss_init_sec_context() and gss_accept_sec_context()
can go off and do things like: DNS lookups, TGS exchanges, certificate
validation (including OSCP and/or CRL checking), ...  All those tasks
must complete before those functions can return, but each of those tasks
can take a long time to complete or fail to complete.

I.e., we want versions of gss_init/accept_sec_context() that will do as
much work as they can, then return without necessarily completing their
work, instead returning some completion event object so the application
can wait for completion in its event loop.

The basic problem here are is that async APIs tend to be very
OS-specific.  But I think we can still have an OS-agnostic design IF we
can rely on background threads (i.e., on a multi-threaded process
model).  Relying on bg-threads might not be feasible on systems where a
multi-threaded process model can't be relied upon (well, on such systems
the async functions can just always operate synchronously when called in
a single-threaded process).

Nico
--