Proposal for debugging API in 1.3.2

[Jeffrey Altman]

I do not believe that this is in conflict either with the approach I 
suggested
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.

- Jeff



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
>   proposal.
>
>_______________________________________________
>krbdev mailing list             krbdev at mit.edu
>https://mailman.mit.edu/mailman/listinfo/krbdev
>