Services4User review

[Greg Hudson]

On Fri, 2009-09-04 at 14:56 -0400, Nicolas Williams wrote:
> MIT has already added non-standard GSS-API extensions.  So has Sun.  So
> has Heimdal.  We're working towards having an IANA registry for GSS-API
> extensions.  That should be good enough.

I should clarify my position:

  * I am fine with adding unstandardized GSSAPI extensions which have a
well-defined purpose.  (Thus, gss_acquire/add_cred_impersonate_name is
okay because that's how we do S4U.)

  * I am fine with adding standardized GSSAPI extensions which we don't
have an identified need for, if resources are available to do so.  For
example, I don't know if we have a current use for gss_store_cred, but I
wouldn't think to raise any objection on principle if someone wanted to
implement it in our tree.

  * I see no benefit in adding unstandardized APIs for no particular
reason, nor do I see any benefit in standardizing
gss_acquire/add_cred_impersonate_cred.

  * When I said "code that isn't tested doesn't work," I meant that code
without an identifiable need is likely to bitrot or simply be non-useful
in the first place, even if it's covered by a regression test suite.

> I don't care that much.  But this is the sort of thing where actual
> experience helps.  So I'd rather it ship, preferably with a warning
> that it's subject to change/removal/...  (That's what we did with
> gss_store_cred(), for example.)

I would much rather apply the YAGNI principle, since it is easier to add
interfaces than remove or change them.