Hello again! Alex van den Bogaerdt wrote:
> Tobias Oetiker wrote: > > [snip: multiple canvases to form one graph] > > > | > Interesting. How should the user interface look? Read the bottom > > | > paragraphs first before you answer this as it might be sufficient. > > | > > | The user interface, especially if multiple tiled graphs are considered > > for one single > > | image, is definitively an open topic. I still vote for some kind of > > script language. > > > > I already talked to alex about this ... my vision is that we might > > use some xml style language to setup the graph ... if we use svg > > for describing the graph, we need libxml anyways and would thus > > have the parser at hand Then my vote is more specific: use XML to define the images! > But this would still process one canvas wouldn't it? You can of > course create more than one image and stack those (using html or > whatever other method) but this is completely different from > specifying (by whatever means) more than one canvas, specifying > which line should go on which canvas etcetera *inside one graph*. Using the current command line interface, yes, it would be painful. If using a structured language (like... XML) this could fully possible. > Graphing only the canvas is something that is (almost) present. > It is just the whitespace that is still inserted even if you > ask not to graph legends and such. (With a graph or rather canvas height of 10 pixels the whitespace takes up a pretty large amount of the png, that's one reason why I keep bitchin about this :-). > Without judging the proposed change to xml, stacking images not > inside RRDtool but rather in your browser should be easy. I've done exactly this and yes, the perl-code to generate it was pretty painless. However, the image takes a very long time to load as the browser must download a large number of small images. Each image needs it's own HTTP connection. This causes a performance hit. My vision is to provide the option to get what's wanted without using too many graphs. If these bar graphs are consolidated already at the server end before even being sent to the browser, loading the page goes significantly faster. But still, if someone think he/she wants to use a larger number of smaller images and reassemble them on the HTML page using HTML tables, that option should of course exist as well. It has it's potentials too. > > Using more than one canvas in one graph would mean: > - define a canvas (need to do that anyway) > - define another canvas, above, below, left, right, overlayed > - define a line, which canvas to use, other properties > etcetera. (XML... :-) > However, I still don't see why anybody would want to create a > graph containing the y-axis *only*. Obviously you need a canvas > next to it, so why not create a graph with y-axis and canvas > together? One y-axis spanning multiple canvases? > Now, creating more than one y-axis and placing it on either > side of the graph, is something that could be useful. This > can be done using xml inside one graph. This is thus different > from displaying the y-axis and the y-axis alone. Well, we have imaginative people out there who certainly would find a way to use that image containing only a single Y-axis. For instance, imagine you have a page with a canvas and a Y-axis and on that page, you have the option to somehow alter the Y-axis. With a separate image for it, you can easily fix that. Just reload the page with all images in the table intact, except for the Y-axis. Another way to view it, an image with a separate X-axis most certainly is useful and once that code is implemented, how much is gained by NOT implementing the option to have a separate Y-axis? I don't want to overload rrdtool (even if I know that the definition of "overload" is a matter of taste and that taste differs among us ;-) but I'm that kind of person who really hate to run into arbitrary limits when using tools. You know, make the tool generic, allow for bizarre uses and someone out there will actually make something useful out of the more bizarre options. If the code and/or the user interface to the tool gets impossible to maintain because of a specific feature, THEN you can discuss avoiding to implement it. Another thing: I don't want this feature to be included at the very start in 1.1.0. However, I want the code to written with this feature in mind, so eventually implementing it wouldn't be too painful. But I agree, it would be useful to have multiple Y-axis in one image. For instance when plotting response times as well as availability when doing ping measurements, one Y-axis could be the response time in milliseconds, the other Y-axis could be the number of lost pings in a specific time interval. Implementing the code for scaling both these axises as well as their grid would be a challenge (but not necessarely impossible...). > cheers, Best regards /IlvJa > > -- > __________________________________________________________________ > / [EMAIL PROTECTED] [EMAIL PROTECTED] \ > | work private | > | My employer is capable of speaking therefore I speak only for myself | > +----------------------------------------------------------------------+ > | Technical questions sent directly to me will be nuked. Use the list. | > +----------------------------------------------------------------------+ > | http://faq.mrtg.org/ | > | http://rrdtool.eu.org --> tutorial | > +----------------------------------------------------------------------+ > > -- > Unsubscribe mailto:[EMAIL PROTECTED] > Help mailto:[EMAIL PROTECTED] > Archive http://www.ee.ethz.ch/~slist/rrd-developers > WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi -- (Jakob Ilves) <[EMAIL PROTECTED]> {Oracle Global IT, Network Management Group} [Office as well as mobile phone: +46/8/477 3666 | Fax: +46/8/477 3572] - Intranet Home Page: http://jilves.se.oracle.com - -- Attached file removed by Listar and put at URL below -- -- Type: text/x-vcard -- Desc: Card for Jakob Ilves -- Size: 444 bytes -- URL : http://www.ee.ethz.ch/~slist/pantomime/31-jakob.ilves.vcf -- Unsubscribe mailto:[EMAIL PROTECTED] Help mailto:[EMAIL PROTECTED] Archive http://www.ee.ethz.ch/~slist/rrd-developers WebAdmin http://www.ee.ethz.ch/~slist/lsg2.cgi
