KDC Audit project

[Dmitri Pal]

On 01/14/2013 09:28 PM, Nico Williams wrote:
> On Mon, Jan 14, 2013 at 7:44 PM, Dmitri Pal <dpal at redhat.com> wrote:
>> On 01/14/2013 10:38 AM, Nico Williams wrote:
>>> Nested objects are fully supported.  My JSON example was intended to
>>> show this.  You thought that the JSON and dict stuff are completely
>>> distinct, but they are not: JSON bits is just a serialization.
>> If I am wrong do you have a code example to illustrate it?
>> Because I looked at the header and have not seen any place where you do
>> the type casting.
>> So I do not see a function or macro that will return you a
>> heim_object_tout of the heim_array_tand also would allow to look at the
>> object of heim_object_ttype and detect that it is actually an array.
> json-c and Jasson have a single C type that's opaque to represent all objects.
>
> heimbase has heim_object_t, which is an alias of void * but the
> objects have distinct C types (all opaque), so heim_string_t,
> heim_dict_t, ...  Containers take heim_object_t for their values (and
> keys).
>
> I actually think that heimbase should switch to the approach of json-c
> and Jasson.  I've asked Love about it.  If you want duck typing then
> the things need to all be of the same C type and you have to get the
> duck typing right -- this should be the principle.
>
> Except what I'd really like is both, and that would require GCC's
> union extensions.
>
>> Also I do not see the support of the KVP lists.
> There's just dicts and arrays (and DBs), as far as containers go.
> That's sufficient for JSON.
>
>> Here is an example of the code that I want to be able to execute.
>> If this is is something that can be done with this library great, if not
>> but a minor change need, also great, if there is a major chunk of work
>> then I would prefer something like json-c and BTW yes this is the right
>> link.
>>
>>
>>     event_t ev = NULL;
>>
>>    /* Construct event from different parts and pieces.
>>        This shows several values that can be of basic types and then an
>> array */
>>
>>     err = create_event(&ev, name1, format1, value1, name2, format2, value2);
>>     ...
>>
>>     err = add_to_event(ev, name3, format3, value3, name4, format4, value4);
>>
>>     ...
>>
>>     err = create_array(&array);
>>     ...
> This is heim_array_create().
>
>>     err = add_element_to_array(array, data_to_add);
>>     ...
> This is heim_append_value().
>
>>     err = add_to_event(ev, name_array, format_array, array);
> This is your app's.
>
>>     /* Call plugin interface */
>>     err = log_event(ev);
>>
>>    destroy_event(ev);
>>
>>
>>    Inside the plugin there will be something like this:
>>
>>    ...
>>
>>    traverse_event(ev, my_callback, my_data)
>>
>>    this will traverse the event and allow the caller to examine
>> different parts of the event and transform it into whatever the
>> implementer needs: syslog call, message bus call, amqp message, database
>> insert statement, JSON, XML, CSV or something else.
> There's array and dict (and DB) iterators in libheimbase.  There's no
> pre-/in-/post-order tree traversal, but that'd be a good thing to add,
> yeah.

The elements need to have names. You dictionary seems to be by value not
by name. Do I get it right?

>
>> 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.
If you need to construct a path you need it to access a file from the
actual code not for the sake of logging so IMO the path library and the
library that provides path management do not need to be the same.

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

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.
It can create json object, modify it, serialize it, traverse it so it
seems that it already has most of the core things we care about for that
specific use case.

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