KDC Audit project
nico at cryptonector.com
Mon Jan 14 21:59:09 EST 2013
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,
>>> 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.
> 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.
More information about the krbdev