[rrd-developers] Re: rrd format change ?

[Tobias Oetiker]

Today Alex van den Bogaerdt wrote:

 |
 | Jake Brutlag wrote:
 | >
 | > Tobi wrote:
 | > > so if we can find a format for rrd which is better to accomodate
 | > > future changes, I think it would be  worth while doing the changes
 | > > now, and find a way to keep on reading old rrd files instead of
 | > > adding more hacks and going to a better ormat later having evben
 | > > more difficulty supporting old stuff ?
 | >
 | > Okay, so if we are going do this, I think the first step is to abstract
 | > the RRD header from the rest of code. The core files, such as
 | > rrd_update, rrd_create, etc make extensive use of the internal structure
 | > of the header. If the header was encapsulated and only accessed by a set
 | > of accessor functions (obviously I'm thinking in C++, but this is doable
 | > in C), the the other files need not be aware of the format on disk of
 | > the header. The header format can change and the other files (update,
 | > create, dump, restore, info, etc) remain unchanged. This encapsulation
 | > would also confine changes to support different file versions to the
 | > code for processing the header (well, as long as the only the header
 | > changed for different versions).
 |
 | Maybe I don't get it but why change the header at all.  If there
 | is nothing changed in what the header describes, an older version
 | of RRDtool is capable of reading all of the data in the RRD. Any
 | new stuff can be in either a separate file, or appended to the RRD
 | and this is not processed by that version.  The data that it can
 | find, it can process.
 |
 | A newer version of RRD can easely extend an already existing RRD and
 | can do so without needing to modify the header. Just add a new header
 | describing the new stuff at the start of the new part.

my intention when designing the rrdtool format was to have a header
at the beginning of the file which describes the whole file
structure, and thus saves us from having to seek through the whole
file hunting down extension headers ...

the intention behind changeing the header format is to make it even
more flexible by allowing configurability of the data sections of
DS and RRA header areas ...

jakes idea helps protecting the code from such changes as well as
confining the backward compatibility 'cruft' into a clearly
identifieable section of the code.

by having more flexible DS and RRA header sizes, new CF and DS
types can be introduced without any further chnages to the format
... an rrd version which does not understand a certain CF or DS can
simply say so ... even a modular aproach towards CF or DS becomes
thinkable ...

cheers
tobi

 | Maybe do something similar as the GIF format has, introduce a type
 | and lenght field in the header, so that parts can easely be added?
 |
 | cheers,
 |

-- 
 ______    __   _
/_  __/_  / /  (_) Oetiker, Timelord & SysMgr @ EE-Dept ETH-Zurich
 / // _ \/ _ \/ / TEL: +41(0)1-6325286  FAX:...1517  ICQ: 10419518
/_/ \.__/_.__/_/ oetiker at ee.ethz.ch http://ee-staff.ethz.ch/~oetiker


--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://www.ee.ethz.ch/~slist/rrd-developers
WebAdmin    http://www.ee.ethz.ch/~slist/lsg2.cgi