I'd love to see if there's some fundamental limitations of the protocol that prevent this, but nscd and its protocol are woefully underdocumented, and it's not even stable, technically, since it's part of glibc and the server and client can change their protocol whenever they want.
Making a new, properly documented protocol, independent from That One Libc You Want To Get Rid Of Anyway, is probably a good idea.
musl implements it, it's not "part of glibc" anymore in the sense of glibc having final control over the protocol. So it's stable for all intents and purposes.
The protocol has a version number (so no fundamental limitation), and is implemented in 500 + 170 lines of code:
I'd love to see if there's some fundamental limitations of the protocol that prevent this, but nscd and its protocol are woefully underdocumented, and it's not even stable, technically, since it's part of glibc and the server and client can change their protocol whenever they want.
Making a new, properly documented protocol, independent from That One Libc You Want To Get Rid Of Anyway, is probably a good idea.
musl implements it, it's not "part of glibc" anymore in the sense of glibc having final control over the protocol. So it's stable for all intents and purposes.
The protocol has a version number (so no fundamental limitation), and is implemented in 500 + 170 lines of code:
https://github.com/pikhq/musl-nscd/blob/master/src/socket_ha...
https://github.com/pikhq/musl-nscd/blob/master/src/write_val...
Code isn't docs, but reading 670 lines of code is not "woefully underdocumented". Yes, a spec would be great. So, write one.
Especially since the work for the "new" protocol is the same - or is that equally underdocumented?