lprng uses private Kerberos Functions?

[Miro Jurisic]

>While I understand about krb5_xfree() and the whole crypto library
>thing with valid_cksumtype(), I don't feel it's fair to call
>krb5_{read,write}_message an internal function.  I don't believe it's
>used by any code in Kerberos other than the examples, _and_ it's even
>mentioned in the Kerberos API document.  It's reasonable for a developer
>to conclude that it's a public function.
>
>I don't think it _should_ be a public function (and it's not like you
>couldn't replicate it with 5-10 lines of code), but I think it's better
>to call it a mistake and yank it out of the library completely with
>perhaps some notes saying, "If you were using this function, here's
>what you need to do".  And removing it from the API document might not be
>a bad idea, since that's what many people out here have been living and
>dying by for years.

I don't think I ever blamed anyone for using them; I understand how 
people got into that state, and it is our fault, and we're fixing it. 
Of course, there's bound to be complaining -- noone's ever happy when 
you tell them one thing and then go "oh, oops, nevermind" a few years 
later. We will update documentation, we will update sample code, we 
will deprecate these functions, we will not make them disappear 
overnight on platforms where they have been used. However, we will 
also _not_ provide them on Mac OS X, because we don't want to 
perpetuate the mistake, and because it gives us a lot of leverage to 
make people fix the code when they port it to Mac OS X. If you like, 
you can think of it as Mac OS X being ahead of the other platforms by 
some amount of time -- it can ditch those functions right now, 
whereas other platforms have to provide them until most clients' code 
is updated.

meeroh
-- 

<http://web.meeroh.org/> | MIT I/S Mac developer | KB1FMP

"Well, I must endure the presence of two or three caterpillars if I 
wish to become acquainted with the butterflies." -- Antoine de 
Saint-Exupery, "The Little Prince"