[rrd-developers] implementing portable format

[Sfiligoi Igor]

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
>>
>>
>