[krbdev.mit.edu #2676] feature proposal - programmatic retrieval of password expiry

[Paul Moore via RT]

How about this:-

get_init_creds_password_ex
With one additional parameter that is a pointer to a
Struct gic_pw_ex_block
{
	int version;  // = 1
	int expiry_time;
}
This can then become the general extension style for an API: - define a struct to be passed in and create an ex version of the API. The ex block can both be read and written by the function. The version stamp reduces issues with old client code with newer API library

Its not very fancy but
A) it works
B) its systematic
C) it preserved the existing API
D) once an extended version of an API is defined no further mods the the API signtaure itself is needed
E) it is somewhat version safe (if a little naïve)



-----Original Message-----
From: 0000-Admin [mailto:daemon at MIT.EDU] On Behalf Of Sam Hartman via RT
Sent: Saturday, August 21, 2004 12:40 AM
To: Paul Moore
Cc: krb5-prs at mit.edu
Subject: Re: [krbdev.mit.edu #2676] feature proposal - programmatic retrieval of password expiry

>>>>> """ == " Paul Moore " via RT <rt-comment at krbdev.mit.edu> writes:

    "> Is this a useful feature. Would you like the diffs?


It sounds like a useful feature, but unfortunately not a useful API.
The problem is that things tend to get too cluttered if we keep adding APIs like this to add one new argument.  krb5_mk_req_* is an example of this gone badly.

The strategy we'd like to adopt is to add an extension mechanism to an API whenever we find that the API is inadequate.  We've had some internal discussions of how to do this for the gic API, but none have been particularly satisfactory.