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
