On Thu, Aug 25, 2011 at 12:56 PM, Angus Salkeld <[email protected]> wrote:
> On Mon, Aug 08, 2011 at 09:41:10AM +0200, Jan Friesse wrote:
>> Current objdb/confdb is really hard to use, because of all iterationing,
>> ... It would be nice to replace it by hash table and thus for simple get
>> item or set item, no iteration is needed. But iteration functionality
>> should still somehow be there to allow user select for example all
>> totem.* items. API proposal to be send later.
>
> Honza, here are some ideas...
>
> The Good
> ========
> it stores
> - current config
> - stats + statistics
>
> What is nice is that you can:
> - dump this out at runtime and inspect it's state
> - you can also modify the objects using objctl
> - you get notification when values change
>
> The Bad
> =======
> 1] The API is not easy to use
> iteration and searching are clumsey
> creating/finding a nested object is teadous
Shrug. Its not so different to recursing through xml without xpath.
> 2] Typing is not done well
> so config is added as strings but needed later as say ints
> and there are no helper functions for this
> 3] Updating the statistics is starting to use more cpu than it should
> To update an entry we have to retrieve it (memcpy's + refcounting)
>
> Possible Solutions
> ==================
>
> 1] API
> We really just want to get/set values do we really need a tree?
>
> Use a map instead of tree data type
> [+] This will make finding and creating objects easier (less code)
> [-] adding notifications to each node is a bit expensive in memory
>
> /* API (ignoring typing & storage for now) */
> map_get(key, ...)
> map_put(key, ...)
> map_del(key)
> map_track(key, notifications)
> map_untrack(key, notifications)
>
> /* of course if we use a hashtable there won't be any sensible order
> * but we could use a skiplist or binary tree.
> *
> * so pass in the prev key (don't store current node) in case of
> * nodes getting destroyed whilst we iterate.
> */
> char* key;
> char* val;
> map_iter_t* i = map_iter_create(m, "statistics/totem/*")
> while (map_iter_next(i, &key, &val) == 0) {
> printf("%s = %s\n", key, val);
> }
> map_iter_free(i);
>
> 2]
> The problem with the typing is we insert different types
> both as keys and values
>
> With C++ collections you would:
> std::map<string, MyObject*> m;
> m["bla"] = obj;
>
> So it's typed and you use these collections for a single purpose (no mixed
> types)
> This makes it really easy to use.
>
> If we want typing and allow different key and values types it will be clumbsy
> again:
> map_insert(m, "a_key", QB_TYPE_STR, "a_value", QB_TYPE_STR);
>
> if we assume the key is a string it's a bit better (we also don't need a
> length for the key):
> map_insert(m, "a_key", "a_value", QB_TYPE_STR);
>
> With some help function it gets better again
> int32_t v = map_get_int32(m, "an_int");
> and we could have str to int helpers:
> int32_t v = map_get_str_as_int32(m, "a_config_option");
>
> 3] objdb currently stores the key and value data (it alloc's the memory and
> memcopies it)
> since we have a deleted_callback can't the owner alloc/free the mem?
> This will make the statistics more efficient if we don't have to repeatedly
> lookup the value
> to increment it. we could just have a ref counting func like:
> map_ref(key)
> map_unref(key)
>
> So it doesn't get deleted under our feet.
>
>
> Regards
> Angus
>
>
>
>> _______________________________________________
>> Openais mailing list
>> [email protected]
>> https://lists.linux-foundation.org/mailman/listinfo/openais
> _______________________________________________
> Openais mailing list
> [email protected]
> https://lists.linux-foundation.org/mailman/listinfo/openais
>
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
