[rrd-developers] Re: abstraction from libart

Burton Strauss Burton at ntopSupport.com
Tue May 17 01:18:13 MEST 2005


Sure ... My interests are simple.  Ha Ha... 

The problem is that whenever somebody goes to install a binary package for
something which uses rrdtool, they pick up the dependences of the package
creator.  If the packager for a particular tool (sigh, usually me) is lazy
WRT a particular distro, everyone who uses that package ends up with a chain
of ugly dependencies.  rrdtool -> Freetype -> XFree86.  Or we have to point
people to a special build flag (Gentoo's USE) or special version (Ubuntu's
gd-noxpm).  Etc.

So what I'm looking for is SOME way to make rrdtool more standalone.  Even
at the cost of some reduction in capabilities.

-----Burton


-----Original Message-----
From: rrd-developers-bounce at list.ee.ethz.ch
[mailto:rrd-developers-bounce at list.ee.ethz.ch] On Behalf Of Gifford Hesketh
Sent: Monday, May 16, 2005 5:57 PM
To: rrd-developers at list.ee.ethz.ch
Subject: [rrd-developers] Re: abstraction from libart

On 5/16/05, Burton Strauss <Burton at ntopsupport.com> wrote:
> As long as you are doing all the work :-), how about making it dynamic?
> <grin, duck and run />
> 
> Compile all of them you find are possible and then use the 'best' one 
> which really exists at run time.
> 
> This would make rrdtool a lot less complex to package, and/or avoid 
> the problems we've had with 1.0.x pulling in half of XFree86...
> 
> -----Burton

I am thinking about interesting ways to do that.  I like some aspects of the
Apache module system, where you can either compile-in or runtime-load
modules.

There could be some "builtin" rrdtool (or librrd, I guess) output providers
-- SVG and PDF, for example.  Other output providers could "register" as
being able to generate a given format.  The provider used could perhaps be
selected by the user (as an option) or by the code after "benchmarking"
different providers that claim support for the chosen format.

If we toss around some ideas, we might find something useful.

--
Unsubscribe
mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi

--
Unsubscribe mailto:rrd-developers-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-developers-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-developers
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi



More information about the rrd-developers mailing list