[rrd-developers] Re: Architecture-dependent RRD file format
oetiker at ee.ethz.ch
Mon Oct 29 08:36:29 MET 2001
Today Matt Zimmerman wrote:
> On Mon, Oct 29, 2001 at 07:37:15AM +0100, Tobias Oetiker wrote:
> > Yes the problem is the numerical storage format ... it is the quickest
> > to do it that way, but it becomes architecture dependent ... the
> > cleanest solution would be to offer the option of using xdr as storage
> > format ...
> > This could be specified when running rrdtool create (or restore) and
> > then the resto of the tools would recigniyze the data as being xdr and
> > convert it accordingly ...
> This doesn't sound like too much work, though it would require breaking
> backward compatibility. If the xdr routines are used for RPC, they
> should be pretty quick, and the code in glibc looks simple, so the
> performance impact should not be too great.
> Are there other changes already in progress which will break backward
> compatibility? That is, will the rrd_version be incremented? If so, I
> would be willing to do some work on implementing an xdr-based format.
well there are features in the development tree which break
backward compatibility but they are done in a way, so that if they
are not used, still the old format is used ...
I would imagine an implementation where usage of xdr is optional
... if rrdtool is used in an embeded system it does not make sense
to require xdr ... even worse it may not be available on all
I could see xdr even going into the 1.0.x tree if it was done in a
way where the format was recogniced from the magick cookie in the
rrd header ...
______ __ _
/_ __/_ / / (_) Oetiker, ETZ J97, ETH, 8092 Zurich, Switzerland
/ // _ \/ _ \/ / phoneto:+41(0)1-632-5286 faxto:+41(0)1-632-1517
/_/ \.__/_.__/_/ mailto:oetiker at ee.ethz.ch http://people.ee.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
More information about the rrd-developers