Hi Tobi. If you can suggest how to xport on the fly the part of the file a user may be interested in without running any active content on the Web server, I would be glad use it. I just cannot think of any way this could be implemented.
PS: Just in perspective; I expect O(10k) RRD files updated once a minute while the typical read access would be O(10) files every few minutes. (O(1) concurrent users) Anyhow, I just wanted to point out that there are real use cases that the portable format should be able to make a reality ;) Cheers, Igor Tobias Oetiker wrote: > Hi Igor, > > if you want to export the whole rrd file (and think this is faster > than xporting the right part of it) then the new portable format > will certainly open the possiblity to write a client in java > runnning in the browser that understands the rrd format ... I can't > see why this should not be possible. I don't think it is efficient > though ... > > cheers > tobi > > Today Sfiligoi Igor wrote: > >> Hi Tobi. >> >> Maybe I was not clear what was the use case: >> I have a server with O(10000) RRDs that are updated ~ once a minute. >> >> I would like to allow a user to look in any one of them (or a >> combination of them) and represent the data in graphics format. >> >> Moreover, I don't want to allow active CGI scripts on my Web server; >> I would just like to export the RRD files. >> >> The ideal scenario would see a Web browser applet that gets the user >> input, fetches the needed RRD files and plots the graphs for the browser. >> >> Today this is effectively impossible; the RRD files are usually not >> understood by the browser due to platform differences. >> >> With the advent of a portable format, this would change, and one could >> hope to implement the above scenario. >> However, it is imperative that the RRD file can be parsed from languages >> that can be used to create client-side Web content, like Java and >> JavaScript. (C/C++ is definitely NOT an option) >> >> PS: So the rrdtool xport is not an option. >> I cannot afford to convert each RRD file into an XML file at each >> update; that defeats the whole reason to use RRD in the first place. >> >> Hope this explains, >> Igor >> >> Tobias Oetiker wrote: >>> Yesterday Sfiligoi Igor wrote: >>> >>>> Daniel Pocock wrote: >>>>> - I've also had a play with JRobin a while back, it is neat for a J2EE >>>>> developer - we should look to interoperate with Java at some level - it >>>>> could be interesting to combine rrdtool data with tools like >>>>> JasperReports (for report presentation) and iReport (for interactive >>>>> report design) >>>> I strongly back this one. >>>> >>>> I have been looking for a long time to have a RRDGraph to be run in the >>>> user browser (no need for creating the graphs on the server side). >>>> Having a Java client for that would be a lifesaver. >>> With rrdtool xport you can create an xml representation of your >>> data which should (?) be comprehensible by java reporting tools. >>> >>> xport could be enhanced to spit out JSON format to enable simple >>> interop with json based tools ... also maybe a native XPORT format >>> would be nice so that frontends can easily convert the data without >>> having to parse xml first ... >>> >>> cheers >>> tobi >>> >>> >>>> My 2c, >>>> Igor >>>> >>>> >> > _______________________________________________ rrd-developers mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-developers
