Namespace for augmented data

Hm, I can see that using string values instead of the ConfD-specific “internal values” can make sense in some scenarios (and for a data provider you can actually have ConfD do it for you, by using the CONFD_DAEMON_FLAG_STRINGSONLY flag with confd_init_daemon()). But turning the hkeypaths into strings, and then having to parse the result and do string compares to figure out which part of the data model is referenced, instead of just switch()ing on the integer hash values, doesn’t seem like an obviously good idea to me…

(There is a reason that hkeypaths are used ConfD → application, and “string paths” in the other direction - hkeypaths are simple to analyze but difficult to construct, while “string paths” are difficult to analyze but simple to construct. ConfD does all the hard work in order to make the application writer’s job easier.:-))