Re: Mechanism extensions and the GSSAPI

[Christopher <cmaxwell@themanor.net>]

On Mon, 3 May 2004, Sam Hartman wrote:
> >>>>> "Christopher" == Christopher  <cmaxwell@themanor.net> writes:
>     Christopher> Maybe this is oversimplistic, but why not provide the
>     Christopher> shims as library/source to be linked into the
>     Christopher> application that deal with the ioctls below the
>     Christopher> applications view of them?
> 
> This seems more complex for authors of applications than being able to
> depend on shims being present.
> 
> ALso, it means you need to specify a stable, extensible protocol
> between the shim and the mechanism.  That's significant work that you
> avoid by making the ioctl specification a mechanism implementation
> matter.

Maybe I misunderstood the earlier conversation, but I thought the shim
was to be the stable API between the application and the ioctl
interface?

Since we are talking about extensions to mechanisms, if ioctl becomes
the stable, extensible protocol between applications and the mechext,
then the shims become tied to the application. (which is the only part
that really knows what extensions it is relying on) and therefore has
all the shims it needs, since it linked them in at build time.

I'm not saying that a set of well-defined basic shims would be a bad
idea, only that it appears to make more sense for them to be tied to the
application.  If an extension is removed, the shim->ioctl would return
an error, rather than breaking linkage to gssapi.