[1813] in Kerberos_V5_Development
Re: Krb5 Ccache DLL proposal
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Fri Sep 27 13:50:01 1996
Date: Fri, 27 Sep 1996 13:49:32 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: "Theodore Y. Ts'o" <tytso@MIT.EDU>
Cc: mikec@geek.grf.ov.com, harryc@cam.ov.com, pbh@MIT.EDU, krbdev@MIT.EDU,
dosdev@MIT.EDU
In-Reply-To: [1800]
Comments on the API:
- You define cc_typed_data but do not talk at all about the legal or
defined values for type. If they are all application-defined, you
should say so. However, since the addresses field is a cc_typed_data,
I doubt *all* of them are app defined.
- You define cc_typed_data and cc_data. Only the ticket and
second_ticket fields are cc_data. Why not declare them to be
cc_typed_data's and then define a type constant for them? That would
eliminate a data structure.
- There is no explicit versioning information in the api. Is that
handled by some standard DLL mechanism? If so, will that be
translateable into Unix implementations of this api? If not, perhaps
it should be explicitly versioned.
- There is no function to deallocate the cc_creds allocated by
cc_seq_fetch. Also, also it is implicit in the type definitions, you
should state explicitly the allocation scheme (caller allocates
structure, callee allocates contents).
- cc_lock/unlock specify no-modify locks. There is different from the
normal shared/exclusive lock semantics; why?
- What happens if you call cc_lock multiple times?
Barry
