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... H ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
