On 09/01/2011 05:17 AM, Jan Friesse wrote: > Included is API proposal for replacement of objdb/confdb API. It should > keep all good things there (triggers, ...), remove hard to use bits > (like whole object idea) and improve existing things (like typing) > > Even I wrote it before, also configuration file will need change. > > Proposed change is > > ht_key value > ht_key. { > ht_subkey value2 > } >
We absolutely can't change the config file - it will cause massive confusion in the user base. Although changing the internal representation in whatever way is necessary seems fine. If the parsing code has to be suboptimal that is preferable to confusing the user base. > which is (internally) converted to > ht_key value > ht_key.ht_subkey value2 > > Also value should become typed, so > value ~= ^-?[0-9]+$ = integer 32 bits, with modificators like l, ll, ... > value ~= ^-?[0-9]*.[0-9]*$ = float (or double) (also should handle all > variants with E .. basically C format) > value = "[:alpha:]*" = string > value = bin:base64 encoded binary data > > Regards, > Honza > > The API looks really solid. I don't totally like the error returns in cht_get and set calls, but understand the need for the programmer to be able to determine what went wrong with the API call. If we didn't have typing we wouldn't need error codes, but I am pretty certain we need typing in corosync (but perhaps not the underlying libqb). A typical map doesn't need an error code because it doesn't care about errors (worst case error, malloc = whole system going to blow up anyway). The only other option is asserting in libs, which is evil, so we should count that out. On the topic of prefix, this is a great feature, but doesn't fit in well with a hash table. Another option is to use direct integration in the skiplist in libqb to implement this. Since what you are delivering on not really a hash table, but more like a map table, may consider a rename to cs_map or similar Really great work Feed missing requirements for libqb into Angus's work on libqb when you start progressing with implementation. Regards -steve > > _______________________________________________ > Openais mailing list > Openais@lists.linux-foundation.org > https://lists.linux-foundation.org/mailman/listinfo/openais _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais