KDC Audit project

[Dmitri Pal]

On 01/08/2013 09:29 PM, Nico Williams wrote:
> On Tue, Jan 8, 2013 at 7:30 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> Yes JSON seems like a good option.
>> However it would require encoding and decoding on the interface boundary.
> I meant that the resulting records should preserve structure, not that
> callers should provide JSON!  And I alluded to how they should provide
> the data: as C types that are duck-typed arrays and dicts and scalar
> values, like in Heimdal's libheimbase, which MIT borrowed a bit from.

Yes. The best would be to have an external (loadable) library like
libcollection, libdhash, librefarray, or json-c that both the provider
and plugin implementer would dynamically link with. That would provide
the passing of the structure data of the interface boundary. This is
what I mostly care about. What the plugin does with this data is
secondary. I would expect it to send it to some destination in some
structured form but since there are different destinations and different
formats (KVP, CEE, JSON, XML etc.) I expect different implementations of
the consumer plugin over time. But we need to start with one that would
be simple and would do the basics.
IMO the best would be to take structured event passed to the interface
and send it to the systemd journal as KVP pairs.     

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