KDC Audit project

[Dmitri Pal]

On 01/14/2013 09:59 PM, Nico Williams wrote:
> 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.

But this is out of the scope of the current project. This is a part of
the server that would do analytics.
I doubt that any of the logging plugin implementations would need this
functionality.
If the path is a value it should be just sent to the right destination
as is.

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

http://git.fedorahosted.org/cgit/ding-libs.git/tree/
>
>> 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.

As you said it misses the traversal. Also dictionary usually does not
preserve the order while lists, arrays and trees do so dictionary of a
small value for event logging. Getting things out of order kills
serialization.

You have arrays, lists can be represented via arrays though it is not
convenient especially for KVP lists. Yes you can probably emulate it by
using array of two elements one for key and another for value and then
have the list to be an array of such elements. This is fine as low level
implementation but should be abstracted. This abstraction does not exist
though.
In JSON you do not need to abstract anything as it stores typed data
reflecting exactly the way you are constructing object.

My last point is that heimbase and ding-libs are one offs and going to
rot over time because they are consumed by a very limited number of
projects while things like JSON libraries have a good chance to survive
our retirement as they are used by many consumers.

>
>> 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.

Agree. This is last resort for the case when we can't get to the
consensus  :-)


> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
>
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/