Hesiod grplist Implementation

I plan to implement support for the "grplist" Hesiod Type, and would like some 
advice and/or sanity checks.  It seems that the best way is to modify 
getgrouplist() and make it little more than a call to nsdispatch(), similar 
to getgrent_r().  I would write backend methods such as files_grplist, 
dns_grplist, etc. to be called from nsdispatch.  My *_grplist methods would 
need to iterate over their respective databases, essentially calling getgrent 
but without going through nsswitch.  The obvious way to do this without 
duplicating a lot of code is to call the corresponding methods from 
getgrent.c, such as files_group.  The problem is, they are static methods, 
and not visible from getgrouplist.c.  Could they be [renamed and] exported?  
Could getgrouplist() be moved into getgrent.c?  How else could this problem 
be solved?

Should the group-%d "compatibility" be retained as a fallback in the absence 
of a grplist RR for the given user?  Are there any sites out there using 
Hesiod /without/ grplist RRs?  There is no real need to remove it, but...

Using all configured services to find group memberships seems most logical.  
Otherwise, where would I stop?  Stopping on a "first match" doesn't make 
sense.  Opinions?

Thanks in advance,
Eric

-- 
Eric van Gyzen                        Sr. Systems Programmer
http://www.stat.duke.edu/~vangyzen/   ISDS, Duke University