KDC Audit project

[Nico Williams]

On Mon, Jan 14, 2013 at 8:54 PM, Dmitri Pal <dpal at redhat.com> wrote:
> The elements need to have names. You dictionary seems to be by value not
> by name. Do I get it right?

Dicts in heumbase allow any type as key, but JSON allows only strings,
of course.

>>> While I see a lot of basic elements available in the library you provide
>>> but I do not see the name value hierarchical management I am talking
>>> about here.
>> The path functions definitely help.  Does json-c have that?
>
> No but the path management is the least thing you need for the the
> logging itself.

Indeed, but for *parsing* log entries path functions are quite handy.

> You might want to consider merging your library with ding-libs or
> copying code from ding-libs.

Link?

> Right now ding-libs has:
> * collection interface that allows you to create and traverse complex
> trees of typed KVPs
> * path_utils - equivalent of the XPath
> * refarray - elastic array like yours
> * dhash - a bit more advanced dictionary than yours
> * simplebuffer - basic serialization interface
> * ini_config - ini file parser

I actually have code for changing the Heimdal registry and .plist
parsers to use heimbase; the code gets significantly smaller and
cleaner that way.

> What it misses is something like the interface that I was suggesting
> that would combine tree with arrays but json already does it so as much
> as I like my art IMO JSON wins as it has ability to store KVPs, nest
> objects into objects, express arrays.

I really don't understand what you think heimbase is missing.  It does
nesting as you describe.

> I actually suggest that we create a layer that would abstract us from
> the JSON implementations like we did with libvirto so that if we switch
> from one library to another we would need to change one layer. This is
> however more work and can be treated as an RFE for future.

Possibly, but such a layer seems like just so much overhead.  Better
pick just one library.