[rrd-developers] implementing portable format

[Sfiligoi Igor]

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