Hi Hamish, Yesterday Hamish Marson wrote:
> Quoting kevin brintnall <[EMAIL PROTECTED]>: > > > I have some more ideas on the implementation... I tried to list the > > categories in increasing order of difficulty. I'm sure I'm missing a few > > gotchas, but these strike me as the major categories that need work. > > > > Looking for feedback on these... Let me know if I'm off-base. > > > > ----------------------------------------------------------------- > > > > CHOICE OF ON-DISK ENCODING: > > > > * estimate user base, choose most common architecture for native format > > - probably i386? > > > > * choose a specific byte-string for RRD portable NAN, INF. Conversion > > routines will have to test specifically for this and convert between > > "RRD NAN" and "native NAN". > > > > ----------------------------------------------------------------- > > > > [deleted] > > As long as it's noted in the header, what sort of format various > numbers are encoded as, what about making the reading of any type > possible, but only write in the native format... Thus if an RRD is > opened in read-write mode, have rrdtool able to convert an RRD from > the encoded format into native format... (Either using something like > 'rrdtool convert' or with a flag to 'rrdtool update' to doit > automatically - which would only happen once of course). > This would let things like rdrdgraph able to operate still without > conversion, but make it possible to move files across easily from one > architecture to another... I can't see anyone would ever want to write > to the same RRD from multiple architectures simultaneously... This sounds like quite a bit of added complexity. It would require us to be able to convert from all platforms to all other platforms ... I have the feeling that adding one new format with the ability to read the old one already puts quite something on our plate. cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch [EMAIL PROTECTED] ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
