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 /_/ \.__/_.__/_/ [EMAIL PROTECTED] http://ee-staff.ethz.ch/~oetiker -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi