Hi Thorsten, Yesterday Thorsten von Eicken wrote:
> Well, if you open the discussion... I'd love to see the following: > - RRDTool sans rrdgraph at the bottom layer for managing the data storage > - An HTTP/REST style service that provides remote access to the data store > using semantics that are relatively independent of the rrd details (at least > for store/fetch requests, create can have a pile of specific args, for > example) > - An RRD graph library that has a pluggable back-end to fetch the data into > which one can easily plug various storage systems, such as local RRD store, > remote RRD store, or a different store altogether. > I believe the current RRDTool is not that far from the above architecture, but > it's not there. Having an HTTP based service on top of the data layer would > allow for a lot of flexibility. Like it or not, HTTP has become the standard > plumbing, at least in my world. Think of passing the requests through a load > balancer to spread the storage across multiple store servers. Or using HTTPS > for security. I believe in the end the real bottleneck will remain at the disk > level and the HTTP overhead can be accommodated. > > Having the graphing be more decoupled from the storage is something that has > been requested many times over, I believe. I see too chalanges here: * defining 'semantics that are relatively independent of the rrd details * there are many (!) people and tools relying on the present interfaces if you are interested in working in that direction, I would suggest you create a prototype for the webinterface using perl with fastcgi this should give you a good platform to write a REST interface for all apart from the graph / fetch separation ... cheers tobi -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland http://it.oetiker.ch t...@oetiker.ch ++41 62 775 9902 / sb: -9900 _______________________________________________ rrd-developers mailing list rrd-developers@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers