Hi, (I'm breaking the thread since we have moved away enough from the original topic.)
On Sun, Jun 22, 2008 at 12:56:36AM +0200, Tobias Oetiker wrote: > many months ago I wrote down some thoughts on a design for this > > http://oss.oetiker.ch/rrdtool-trac/wiki/RRDaccelerator > > the idea was to have rrdtool use such a daemon transparently ... Adding support for this to the actual `rrdtool' application is of course the best solution and much better than using some wrapper around it. I'd add the following options to `rrdtool <update|fetch|graph|info>': --cache Force use of the daemon. Fail if no socket is found or if connecting fails. --nocache Force using the file directly. Default, if neither `--[no]cache' is given, would be to check for a socket and use it if available. --daemon <address> How the daemon may be reached. In the long run we may not want to limit ourselves to UNIX domain sockets. How the daemon is used depends on the command of course: - update Send values to the daemon rather than writing to the file. - fetch, graph Send a `flush' command to the daemon. - info Get last `last_update' and such. Looking at the list of commands, next to all of them may use the daemon in one way or another.. So far I've put all connection specific stuff in a shared object, so the code is nicely separated from that wrapper. Integrating that into `rrdtool' should be straight forward. For now I'll add code to that and not work on the wrapper much, so that migrating that to `rrdtool' will stay simple :) Regards, -octo -- Florian octo Forster Hacker in training GnuPG: 0x91523C3D http://verplant.org/
signature.asc
Description: Digital signature
_______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
