[1847] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Oct 7 14:00:47 1996
Date: Mon, 7 Oct 1996 13:59:51 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: tytso@MIT.EDU
Cc: tytso@MIT.EDU, mikec@geek.grf.ov.com, harryc@cam.ov.com, pbh@MIT.EDU,
krbdev@MIT.EDU, dosdev@MIT.EDU
In-Reply-To: <199610041633.MAA01896@localhost.mit.edu> (tytso@MIT.EDU)
What are the semantics of the time fields, and what is the actual type
of cc_time_t? If the times are all Unix timestamps (seconds since
1/1/70), then I suggest you replace cc_time_t with cc_int32 because,
admit it, that is what is is going to be anyway and then you have one
fewer type to create and one fewer type to implement incorrectly (with
the wrong width, for example).
In general, besides an API function description, I'd like to see the
spec contain a data type description that specifies the precise
meaning of each field in every structure. See the kadm5 api spec for
an example of what I mean.
I see you created cc_initialize and cc_shutdown to handle API
versioning. Good. However, now you have two opaque handles that must
be passed to every cc function. Furthermore, the startup sequence
will always be the same: call cc_initialize, then call either cc_open
or cc_create. So I suggest that you simply merge cc_initialize into
cc_open and cc_create so that each of those functions takes an
api_version argument, and that information is then stored in the
single cc handle. Again, see the kadm5 api spec for kadm5_init_*
(there are three) for an example.
Your locking semantics do not specify what will happen if a thread has
the cache locked for writing and attempts to get a read lock. I
suspect you intend for this to be a no-op, and if you delete the text
", respectively," from that paragraph I think it will mean what you
want. Also, s/lcoked/locked/.
Your lock semantics still do not allow for multiple locks by multiple
independent (neseted) callers within a thread, because a call to
unlock always completely releases the lock, instead of decrementing a
refcnt. That's fine, although it worries me; I'm just pointing it out
to make sure you intended it. Keep in mind that refcnts are easy to
implement, and you already have a convenient place to store it (in the
handle).
Barry
