Proposal for debugging API in 1.3.2
jaltman at columbia.edu
Fri Feb 6 15:35:12 EST 2004
I do not believe that this is in conflict either with the approach I
yesterday or that I wished to pursue today. My goals are met.
If you define the inline function, I will fill in the rest for the platform
specific use on Windows.
Sam Hartman wrote:
>Today, Jeff, Alexis and I had an extended Zephyr discussion about the
>debugging API. Ken and Jeff's current proposal is not a proposal for
>a debugging API but rather a proposal for a user status messages API.
>It's unclear to me whether user status messages are a desirable
>feature of a library like the Kerberos library. Also, it is clear to
>me there is a significant difference in the debugging approach KFM is
>currently taking and the approach Jeff is suggesting for KFW. The
>option of asserting that one of these approaches is correct is
>unappealing to me because I can see that having a unified vision in
>debugging is important and I don't understand the issue well enough to
>make an informed decision. I believe I can learn to understand the
>issue, but not in the 1.3.2 timeframe.
>There are also significant disadvantages to making a stopgap decision
>now with the goal of fixing it later. In general, people never find
>the time to fix such decisions later. So we should only move forward
>on this issue if we believe the results will be acceptable at least as
>a starting point for a long-term solution.
>I do not believe we can resolve the general disagreement raised today
>for 1.3.2. However I believe there may be a way to move forward. I
>propose the following API. If we accept this API, we should do so
>believing that it will be acceptable even if we never make major
>changes to it.
>A function krb5int_message, taking a facility, format string and
>variable arguments. This function will be defined as a static inline
>function that will either call a platform-specific function or do
>nothing. We will define one facility code, corresponding to the user
>status messages Jeff wants to add now.
>We may define macros for giving krb5int_message a shorter name. These
>macros will not take arguments.
>This proposal addresses my concerns with Ken and Jeff's proposal:
>1) It required multiple macros for each of the possible numbers of
> arguments you might need.
>2) It did not seem like it would expand into a debugging API because
> it was missing facility codes. However it seemed like people might
> start using it as a debugging API rather than revise the API and
> change the existing messages. Alternatively we might end up both
> with a user status API and a debugging API in the same product.
> That seems unacceptably confusing.
>3) Alexis and I are generally concerned about the use of macros in the
>krbdev mailing list krbdev at mit.edu
More information about the krbdev