[328] in Hesiod
Reentrant interfaces
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Nov 13 13:30:15 1996
Date: Wed, 13 Nov 1996 13:25:10 -0500
From: Greg Hudson <ghudson@MIT.EDU>
To: hesiod@MIT.EDU
It's amazing what you find out after you release a piece of software.
Yesterday I found out that a co-worker of mine had done some work over
a year ago to integrate Hesiod into the BIND resolver. He used a very
different approach to reentrant interfaces, one which is more in line
with the way the next releas of BIND likes to do things. In the name
of avoiding divergence, please don't consider the reentrant interfaces
in Hesiod 2.0.0 to be final; the final interfaces will look like:
int hesiod_init(void **context);
int hesiod_end(void *context);
char *hesiod_to_bind(void *context, const char *name, const char *type);
char **hesiod_resolve(void *context, const char *name, const char *type);
void hesiod_free_list(void *context, char **list);
Multiple calls to hesiod_resolve() with the same context will result
in multiple disjoint lists, each of which needs to be freed
separately; the only reason you would need to use different contexts
is if you had multiple threads doing Hesiod resolves at the same time.
There are still passwd, group, service, and mailbox lookups to
consider. BIND is going to be packaged with a library called IRS
which implements something similar to the Sun nsswitch, and in the
ideal future there won't need to be a hes_getpwnam(), because your
system's getpwnam() will go through IRS and use whatever database you
specify. In the short term, I haven't yet decided what to do.
Anyway, expect a Hesiod 3.0.0 out in the near future which supports
the above interfaces and which tries a resolve in C_IN before C_HS.
