Re: GSS-APIv3 sketch

[Nicolas Williams <[e-mail]>]

On Wed, Nov 11, 2009 at 02:41:27PM -0500, Jeffrey Hutzelman wrote:
> --On Wednesday, November 11, 2009 12:55:29 PM -0600 Nicolas Williams 
> <[e-mail]> wrote:
> 
> >>>> Well-defined SPI will force everything to reimplemnent GSS-API
> >>>> semantics in all layer, this sucks and duplicates code.
> >>>
> >>> No, see the compat shims.
> >>
> >>That doesn't answer my question, making the SPI look like the API is the
> >>problem.
> >
> >Actually, I have options to set the SPI symbol prefix to anything you
> >like, so as long as you don't have additional SPI arguments (as we do in
> >OpenSolaris) you're OK.  But ALSO, I did answer your question: providers
> >that don't support he new SPI can be accessed via v2u1 mechglues used
> >through the v3 mechglue (that's what the note about shims was about).
> 
> I think you're missing Love's point.  Regardless of what the symbol names 
> are, if the API and SPI are the same, then both the mechglue and each 
> mechanism have to implement all of the semantics of that interface.  That 
> was sort of necessary with GSSAPIv2, because the mechglue concept was 
> introduced after the original API design, which envisioned selecting a 
> mechanism at link time.  Now that we understand how silly that is, there's 
> no reason to presume that anyone will link to a GSSAPIv3 mechanism provider 
> directly, and so the API and SPI need not be the same.

I didn't say the SPI is exactly the same as the API.  I said "mostly".

The reason for the two to be mostly the same is simple: I can't think of
why I'd want the SPI to be radically different than the API, that is, I
haven't found an implementation reason for wanting the SPI to be
radically different than the API.

In fact, having them be at least very similar helps make the code
generation approach possible.  For example, suppose I created a single
SPI function interface to all per-message token functions -- I sure
could, but then the code generator would have to learn all the specific
details of how to map per-msg token API functions onto that one SPI
function, thus negating the whole point of a code generator approach.

Let's look at possible SPI departures from the API:

 - symbol prefixes -- easy to handle
 - extra arguments, as in the OpenSolaris SPI (which is not open)
    - I don't see a need for such extra arguments, but as long as the
      pattern is regular, it can be easily handled
 - instead of using dlopen()/dlsym() you call a function that returns a
   struct full of function pointers -- easy to handle
    - I also forgot to mention that the mechglue configuration interface
      allows you do implement statically-linked providers if you want

 - radical departures from the API, such as merging API functions at the
   SPI layer -- NOT easy to handle

 - gratuitous departures, such as different argument ordering -- why
   bother??

 - other departures??

Nico
--