Hi, Today Florian Forster wrote:
[...] > What about abstracting from the file layer some more? Much of the > problems (permissions, paths) result from the daemon writing to file > that are read by other processes. It's worth a though to restrict file > access *only* to the daemon. We'd need to add a `FETCH' command as a > first step, so that graphing can be done using information provided by > the daemon, too[1]. `rrdcached' would be more of a database layer over > the actual storage and neither client (updating or graphing) needs to > know the exact location of the data on disk. that thought has occured to me too when thinking about this. We could go the 'database server' route. But this would also make rrdtool less usefull for little projects where people do not want to run daemons and stuff, so the design would have to be such, that we can do both, run 'on demand' as well as in 'server mode'. Doing this right will present us with many new and interesting challenges ... authentication and such come to mind. So maybe an approach where the rrd-graph part was more loosely connected to the rrd-database part would make more sense, since this would enable us to leave a lot communication issues to another layer of software and limit oursefs to provide a sensible means for rrd-graph to access data provided by rrd-fetch ... (or even some other provider) 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
