On 08/25/2011 06:31 AM, Angus Salkeld wrote:
> On Thu, Aug 25, 2011 at 05:16:20AM +0200, Fabio M. Di Nitto wrote:
>> On 08/25/2011 04:56 AM, Angus Salkeld wrote:
>>
>>> Possible Solutions
>>> ==================
>>>
>>> 1] API
>>> We really just want to get/set values do we really need a tree?
>>
>> as you already mentioned before, tree make it easy to load a config file
>> and map it in the objdb following the same structure (object, key etc..).
>>
>> I know Steven wants xml loader too (that matches perfectly with objdb 1:1).
>>
>> Whatever API you want to put in place, please keep it simple to retain
>> the same view even if internally is a map or whatever else you decide.
>>
>> Also consider formats for export. For example dumping the objdb into an
>> xml file is dead simple. The new API should allow something similar IMHO.
>
> Yikes, well converting a map's contents to and from xml is going to be
> interesting.
>
> If we added an xpath-like api to objdb we could improve the API
> enormously and still keep it a tree.
>
> ver = objdb_get_int32("/service/@name=cpg/ver");
>
> objdb_cd("/logging/@subsys=main");
> if (objdb_get_bool("to_syslog")) {
> //...
> }
Possibly, "real" xpath is complex. A subset of xpath is already
implemented in libccsconfdb (that does a reduced set of xpath<->objdb).
The current "full xpath" implementation in libccsconfdb, involves
dumping objdb into xml and use libxml for real xpath queries.. "easy way
out" without re-implementing the world.
Fabio
_______________________________________________
Openais mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/openais
