> How about having the rrd format changed so that at the beginging > of the rrd we have some size specifiers which tell how large the > data area of each DS definition is ... this would allow to create > some sort of forward compatible system which can skip DS types it > does not understand ...
Obviously there are some problems that changing the format could resolve, but I didn't want to be the one to propose it. In a past life (okay, just 5 years ago), I was working in tech support for a small database company and there I learned that backwards compatibility is high priority. In the current design, RRDtool can support version 1 and version 2 RRD files without effort. If the format was changed, the code would need to branch to preserve backwards compatibility. Another personal issue with backwards compatibility is Cricket code. For some reason, there is code used in Cricket to read the binary header sections of an RRD file. Now this is very poor design (for which I am not responsible), but Cricket utilizes the fact that data sources (and everything else in the RRD header) are of a predictable fixed size. Of course, this code could be changed, and would have to be if the format of the RRD header changed. On the otherhand, both the aberrant behavior detection and the COMPUTE data source implementation had to jump through some hoops to fit within the current RRD header structure. If a new, more flexible format, was selected some of the ugliness could be cleaned up. Jake Jake Brutlag ([EMAIL PROTECTED]) Network Analyst Microsoft WebTV -- 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
