[534] in Kerberos_V5_Development
subroutines used by two modules
tytso@ATHENA.MIT.EDU (tytso@ATHENA.MIT.EDU)
Wed Dec 19 00:34:52 1990
This is basically a problem of how do we have private subroutines in the
krb5 library which need to be used by more than one module in the
library, but which we might not want to export out to the API.
I have a pair of subroutines:
krb5_error_code | krb5_error_code
krb5_read_message(fd, inbuf) | krb5_write_message(fd, outbuf)
int fd; | int fd;
krb5_data *inbuf; | krb5_data *outbuf;
which transmits/receives a message using krb5_net_{read,write} by first
sending/exepcting the length as a 32 bit quantity in network byte order,
followed by the contents.
They're used extensively by krb5_send_auth() and krb5_recv_auth()
(currently under development, living in src/slave/sendauth.c at the
moment). I know, I know, I should be using ASN.1 for the sendauth
protocol, but I've seen Jon trying to use it for the admin protocol, and
I wanted something that works, preferably in time for the ALPHA_3
snapshot. Remember the KISS principal....
The problem is that these routines are needed by both krb5_sendauth and
krb5_recvauth. I see the following options:
1) We export krb5_read_message() and krb5_write_message() in the krb5
library. If we don't mind routines like this in the API, we win.
However, if we want them to remain local subroutines used only by
sendauth and recvauth, things get tricky.
2) We put read_message(), write_message(), send_auth(), and recv_auth()
in the same file, and make read_message and write_message be static.
This loses because send_auth and recv_auth are in the same file, and
will both get dragged in when most programs will only need one of them.
3) We separate send_auth() and recv_auth() into separate files, and
make duplicate read_message() and write_message() in both files as
static procedure. This is somewhat wasteful, but given that most
programs will only link in one of the two routines, it's marginally ok.
4) We export read_message() and write_message() in the krb5 library,
but we give them wierd names and not document them.
What do people think?
For now, recv_auth() and send_auth() will be in the slave subdirectory.
I won't install them into the krb5 library until their interface
stabalizes a bit, which might be a while. But when we put them into the
library, these issues will arise.
