[rrd-developers] rrdtool 1.4 development ready to go

[José Luis Tallón]

Tobias Oetiker wrote:
>>> Unfortunately I have not yet seen a api design that convinced me to
>>> switch.
>>>       
>> Will you take a look at what I designed at that time?
>> You will most probably not like it entirely, but it might be a good
>> starting point.
>>     
The most interesting files are attached. The subscribers will have the
tgz intercepted by listar, I assume.
Please keep in mind that this was abandoned very early; I only drafted
the first ideas before passing it on to a student who was supposed to
finish some concept test. Unfortunately, development got stalled and
very little was done before that sub-project got cancelled. It was based
in a very early (1.2.3 or so) 1.2-series rrdtool version.
>> The strategy we used was to re-design everything in C++,
>> object-oriented, and then code the resulting "projection" onto C. The
>> modules each take opaque "handles" and all parameters are passed around
>> in their native binary form ---as opposed to converting back and forth
>> into strings.
>>     
The handle types are typedef'd (void*) pointers, in order to keep them
opaque to users, and "byvalue" semantics were observed whenever possible
--- that is, avoid pointer-like interfaces as much as possible.

The conversion macros all handle the casts from/to those handle types
for use. Therefore, we have two type "families": the public names, with
their typedefs and all, and the actual types, hidden from the user,
which are structures defined within the internal headers. The alloca()
function was used whenever possible within the low-level functions, as
opposed to malloc() so as to reduce the potential for memory leaks.

The variadic interfaces (stdarg-based) are provided for programmer's
convenience: when we already have all parameters, it is easier to just
make one call with all required data and have the RRD created than
making, say, 10 calls to fill in all attributes.

In order to remain compatible with existing RRD files, we just imported
rrd_format.h (which in turn includes rrd.h) and used the structures
defined therein as building blocks. Our internal structures were mostly
groupings of those, to continue the trend: one concept -> one C++ object
-> one C "POD" structure

There exist _alloc and _free functions for all defined types (even when
they simply call malloc() or free() internally) for symettry purposes
and to make wrapping simpler. For example, the C++ constructor and
destructor would just call these functions in most cases. Prefixes are
used to keep module naming consistent: librrdng_ds_* deal with
DataSources, librrdng_rra_ with RoundRobin Archives, etc.

The *.inl files are just collections of "convenience functions", which
would have otherwise been implemented as macros, in order to keep them
together. This makes coding easier since files are shorter and only
cover one particular area.
One module attempted to deal with interrupt-safe I/O, where all
low-level calls were run in a loop. We also did without libc's stdio
wrappers, but the low-level read()/write() and lseek: a later iteration
would have re-implemented those in terms of mmap().

The C++ binding/initial concept was never completed, either. The
"sample" class remained largely undefined, for example. The wrapper
classes for DataSources and RRAs were largely ok, though never got finished.
The interfaces were meant to use STL containers for argument passing
(e.g. const std::vector<RRDtool::DataSource>& , which can be easily
converted into "const rrd_ds_t*" by the way )

The librrd_compat library would have provided functions to "marshall"
and "demarshall" values from argv[] lists. The signatures, of course,
had to be identical to the published RRDtool API to be useful.



As said, this was largely a "proof of concept", and so very little is
actually useable. But it might provide some ideas on what to do (and
what to avoid of course ;) ). Hope it helps.


Best regards,

    J.L.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: librrdng.tgz
Type: application/x-gtar
Size: 9011 bytes
Desc: not available
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20080907/904d9d87/attachment.gtar