On 28/07/09 23:27, Steven Dake wrote:
> On Wed, 2009-07-29 at 07:30 +1200, Angus Salkeld wrote:
>> Hi
>>
>> Here is a first attempt at an easier to use API for objdb.
>>
>> 1) remove the need for parent_handles.
>
> big improvement
>
>> 2) Each object/key must have a unique name (as a string)
>> 2.1) So no child objects named the same (service, logging,...)
>
> need more thought around this as a use case
I really don't like this. It breaks so much existing practice that it
needs a VERY strong case for introducing it. In fact it's so embedded in
both corosync itself and cman that I think that rather than us defending
what's already there you should produce a watertight case as to why it
needs to change.
>
>> 5) less/(no) need for iterators as you can directly asses key using it's
>> path.
>> eg objdb->key_get("/logging/NTF/debug",&debug_on,&debug_on_len);
>>
There will always be a need to iterators. People want to know what's in
the tree. You can't expect everyone to know the contents of the objdb.
Arbitrary things like services are stored there.
>> struct objdb_iface_ver_2_0 {
>> int (*objdb_init) (void);
>>
>> int (*object_create) (
>> hdb_handle_t *object_handle,
>> const char *path,
>> path_notification_fn_t child_validator,
>> data_notification_fn_t data_validator);
>>
>
> imo makes more sense to seperate out the notifications changes from the
> object creation. I can see a case where someone may want a callback
> that an object has changed without actually creating it.
Agreed. Actually this is far more common in my code than tracking thing
immediately after creation (which something I've never actually needed
to do)
>
chrissie
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
