KDC Audit project

[Nico Williams]

On Mon, Jan 14, 2013 at 9:31 PM, Dmitri Pal <dpal at redhat.com> wrote:
> On 01/14/2013 09:59 PM, Nico Williams wrote:
>>> 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.

Huh?  Sure I'd need the functionality to parse a log entry.

> If the path is a value it should be just sent to the right destination
> as is.

Er, no... a path is just a way to address part of a tree structure
(composed of dicts and arrays).

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

Thanks.

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

Well, it's trivial to use the iterators to build a pre-/in-/post-order
traversal.  That should be part of the API though, I agree.

And you want a dict that preserves insertion order.  That is one thing
that's missing, sure.

> 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 don't think that's necessarily true.  I want heimbase to be adopted
by others.  If all say no because others haven't adopted it then... it
still won't rot because Heimdal uses it and depends on it, so it will
at least continue to work as well as it does now.

>> 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  :-)

Please, let's not add a pluggable JSON library layer.