Re: GSS-APIv3 sketch

["Stefan (metze) Metzmacher" <[e-mail]>]

Nicolas Williams schrieb:
> On Wed, Nov 11, 2009 at 05:00:45PM -0600, Nicolas Williams wrote:
>> I think implementations could certainly have such interfaces, but I
>> think we'd not standardize them here.
> 
> On second thought, I think we could do non-threaded async APIs as
> separate RFCs, one for each event interface.  We might end up with only
> one: libevent.
> 
> One sketch:
> 
>  - app calls set_async_XYZ() on a call context handle to register
>    XYZ-specific event loops
>  - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED
>  - app calls init/accept_sec_context() again when a related event is
>    posted
> 
> Another:
> 
>  - app calls set_async_XYZ() on a call context handle to indicate the
>    desire to do XYZ-specific async calls
>  - init/accept_sec_context() return S_ASYNC_CONTINUE_NEEDED
>  - app calls get_async_XYZ() on the call context handle to get
>    XYZ-specific event descriptions that the app then handles in an
>    XYZ-specific way
>  - app calls init/accept_sec_context() again when a related event is
>    posted

I think such models could nicely work from the callers view.
But init/accept_sec_context() should only return A_ASYNC_CONTINUE_NEEDED
once! And the caller gets only notified when the function has completed,
so that the caller can get the result.

The main remaining problem has to do with the mech implementations, they
need an api to register different types of events.

Think about this:

A system has a libgssv3.so with mechglue code and a few
mech implementations by different vendors.

Then some application wants to use libevent with the
libgssv3.so.

On the same box samba wants to use it's tevent library
with libgssv3.so.

And a third application wants to use the glib event code
with libgssv3.so.

The mech implementations should work in all 3 cases
without knowledge about the specific event system.

metze