[1124] in Kerberos_V5_Development
API change proposal: API versioning
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon May 6 16:21:50 1996
Date: Mon, 6 May 1996 16:21:45 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: krbdev@MIT.EDU
Jon Rochlis, Lover of All Things Multics, convinced the OV engineering
team a few years ago to add some kind of versioning system to the
ovsec_kadm api, so that future releases of the product could contain
api changes without breaking previously written code. The idea is
that the libraries and admin server would be able to understand old
api versions, and with the versioning system in place would be able to
tell easily which version to use. So we did it, and it was a good
thing; you can read about the details (albeit not very much of the
rationale) in specs/admin/lib/versioning-funcspec.tex and
specs/admin/lib/api_server_tools_funcspec.tex.
I believe the krb5 api needs the same kind of thing. We want to
release krb5 1.0 soon, but it is almost certain that the krb5 api will
not be 100% "right" in the near future (particularly given its lack of
documentation). Even if it were right, we'd certainly want to make
changes in the future.
The beauty of introducting a versioning system is that it takes
essentially no work up front; you only have to deal with it in the
future when you define a new version and change a function's behavior.
Basically, the only change you need to make is to add a new argument
to the init function,
krb5_error_code INTERFACE
krb5_init_context(context, api_version)
krb5_context *context;
u_login api_version;
and then store the version value in the context structure. Version
constants (KRB5_API_VERSION_1, ...) are defined in krb5.h. krb5
functions that depend on the api version then check the context to
determine how to behave.
If people think this is a good idea, I'll write up a more careful
explanation of the change, how it will work, and how new versions will
be handled.
Barry
