CometVisu - (interner) Beta-Test

[makki]

Soweit meine Vermutung.

100 Punkte
Wenn ok, kann ich das auch gleich commiten ?

Edit: An den Dropdowns im Editor mit Chromium ändert das aber nichts..
STOP: Kommando zurück! Lowercase ändert nichts, schon schlau wenn man 20 Fenster offenhat, die eine SVN ändert und dann im C statt FF anschaut

Makki

[netzkind]

@makki:
ich hab grade bei mir mal den cache geleert und anschließend mit FF 3.6.12 http://mm-ho.dyndns.org/visu-svn/ geöffnet - bei mir läufts problemlos.

Cache leeren um keine alten JS einzubinden?

Grüße,
Julian

[makki]

Browser-Cache

Peinlich, peinlich
Mit Cache leeren gehts im FF, bisher hat strg+F5 immer gereicht;

Und selbst das sollte doch nicht notwendig sein! Ich werd das "fürs Feld" jetzt mal näher untersuchen und was man ggfs. dagegen tun kann, weil eigentlich frägt der Client den Server ja deswegen mit "If-Modified-Since" + all dem Zeugs im Header.
Und der Server antwortet doch bitte nur mit 304 wenns seitdem nicht geändert ist (oder eben nicht wenn geändert) !?!
Da fehlt evtl. noch ne klitzekleine Einstellung..

Makki

[netzkind]

r172:
- im Chromium gehen die Edit-Dropdowns jetzt seit dem letzten Update nur noch "irgendwann"

Kann ich hier Chrome 7.0.517.44 reproduzieren - der lässt mich nicht mal mehr in die inputs schreiben. Spontan hab ich keine Idee woran das liegt - habe es aber auch noch nie mit Chrome probiert gehabt: lief es da denn überhaupt schon mal?

Grüße,
Julian

[makki]

lief es da denn überhaupt schon mal?

Definitiv, ja ich kann Dir aber ehrlichgesagt nicht sagen wann&was; heute Nachmittag klappte das mit einer noch, ich glaube es war post 0.5.1 aber pre-SVN von heute.
Die Visu selbst ist im Chrome sogar hier erheblich "smoother" als im FF (ich vermute aber Chris entwickelt auch mit Chromium, weil von ihm hab ich den Trigger dafür)
-> Mein neuer Lieblingsbrowser, ist dasselbe wie FF vor ein paar Jahren: schlank, schön, schnell

Hier auch 7.0.517.44 (64615) Ubuntu 10.04

Makki

P.S.: Damit Mitleser das auch einsortiert bekommen: Chrom(ium) basiert auf Webkit, eine aktuell wohl als eher ziemlich gut angesehene OSS "Browser-Engine" - auf der auch der Safari basiert.
Wir denken hier also auch an die iStore-Junkies

P.P.S.: Wenn mir jemand das mit dem Cache-leeren erklären kann -> ??
Ich hab jetzt mal ein bisschen getestet; ändere ich ein .js am Server reicht in 100% der Fälle ein normaler F5 und die aktuelle Version wird geholt.
Ich kreide das ja nicht der Cometvisu an, sondern entweder dem client (daran kann ich nix ändern, nur workarounds bauen) oder dem Server (daran könnte ich was ändern!).
Aber es ist IMHO ein zu lösendes Problem, bei einem Update Cache leeren ist ein Workaround, kein Fix

[vento66]

So die aktuelle Visu aus dem svn bringt nur einen black screen, die Fehlerkonsole meldet unter Chrome:

Failed to load resource: the server responded with a status of 404 (Not Found)
visu_svn/visu/plugins/colorChooser/structure_plugin.js

Uncaught TypeError: Cannot call method 'create' of undefined
/visu_svn/visu/lib/templateengine.js:233

Das erstere lässt sich mit umbenennen des Ordners colorchooser nach colorChooser beheben, für die 2. Meldung fehlts mir dann an Wissen

[Chris M.]

So die aktuelle Visu aus dem svn bringt nur einen black screen, die Fehlerkonsole meldet unter Chrome:

Failed to load resource: the server responded with a status of 404 (Not Found)
visu_svn/visu/plugins/colorChooser/structure_plugin.js

Uncaught TypeError: Cannot call method 'create' of undefined
/visu_svn/visu/lib/templateengine.js:233

Das erstere lässt sich mit umbenennen des Ordners colorchooser nach colorChooser beheben, für die 2. Meldung fehlts mir dann an Wissen

Nein, bitte nicht den Ordner umbenennen - den habe ich wg. dem Kommentar zum camelCase extra in lowercase umbenannt.
Ich vermute, dass Du Deine visu_config.xml noch diesbezüglich anpassen musst.

Übrigens: entwickeln tu ich unter FF, meine Visu läuft mit Chromium. (Und um vom Arbeitsplatz mal schnell schaun zu können, hab ich Interesse an IE7)

[Chris M.]

Im Source hatte ich noch zwei Zeilen vergessen zu ändern - d.h. spätestens jetzt sollte es wieder gehen (aber die eigene visu_config.xml anpassen nicht übersehen, s.o.)

[luigi4711]

Funktioniert

[netzkind]

Hi makki,

Ist das json so genehm? (siehe http://mm-ho-dyndns.org/cgi-bin/rrdf...-1day&res=1800 - das ist NICHT das in /oldvisu verwendete - 100x awk&grep weniger )
Hab kurz das rrdtool umgehacked, das es gleich json ausgibt, wie man das distributionstechnisch eintütet..
Die Timestamps sind UTC, die Daten %0.2float

wo bekomme ich das denn her? Flot-Einbindung scheint jetzt nicht wirklich so schwer zu sein, schwerer zu entscheiden wie man es optisch haben will

Grüße,
Julian

[makki]

rrdfetch

Ganz dirty hier

Mir hat das alles nicht getaugt, bzw. wars mir 200ms zu langsam deswegen hab ich einfach kurz das rrdtool auf json-Ausgabe umgeschrieben
Zum testen reichts, bei einem Release wird man sich da was anderes ausdenken..

Makki

[makki]

zum rrdfetch noch:
Die timestamps sind UTC, ich denke das ist Ok (kennt man im JS/Browser die lokale TZ?) - ansonsten sollte man das Datenformat evtl. noch mit aktueller lokaler TZ am Server erweitern?)

Und ich hab gerade mal ein bisschen mit gzip/zlib dafür gespielt:
- Performanceunterschied an Client&Server: nicht messbar
- übertragene Datenmenge: natürlich 1/3
- macht via Wlan&GSM schon wieder ggfs. 100ms (ok, wir sprechen von 200 vs. 300..)
(wer probieren will: genannte URL und rrdfetch-gz statt rrdfetch)

Makki

[netzkind]

Hi makki,

Zum testen reichts, bei einem Release wird man sich da was anderes ausdenken..

mir reichts leider nicht
Die rrdtoolj gibt im Body ein "Content-type text/plain" aus - das ist am falschen Ort, und richtig wäre auch "application/json". Ich würds an der Stelle einfach ganz rausschmeißen, das kann das shellskript übernehmen.

Und die Daten sind nicht valide (vergleiche JSONLint - The JSON Validator.).
Ideal wäre es die Daten einfach als array zu bekommen, nicht als Objekt, also

[
    [
        1290631500,
        417.18 
    ],
    [
        1290633000,
        451.21 
    ],
   ...
]

Zusätzlich wichtig ist, dass vor schließenden ] keine Komma gesetzt sein dürfen - sonst ist es nicht valide.

Da ich leider nur die binary-Version von rrdtoolj habe bin ich da jetzt auf deine Zuarbeit angewiesen

Grüße,
Julian

[makki]

Content-type: uuups
War wohl ein sehr schneller Quickhack..

und richtig wäre auch "application/json". Ich würds an der Stelle einfach ganz rausschmeißen, das kann das shellskript übernehmen.

application/json kann man nur nicht so schön im Browser gleich sehen - ist geändert.
Das Shellscript soll natürlich am Ende des Tages eigentlich ganz weg, aber obs die 20ms jetzt rausreissen?...

Ideal wäre es die Daten einfach als array zu bekommen, nicht als Objekt, also

Deswegen fragte ich ja

Da ich leider nur die binary-Version von rrdtoolj habe bin ich da jetzt auf deine Zuarbeit angewiesen

Ich eile, diff zu meiner Entlastung im Anhang

Allerdings wärs 30 Minuten schneller gegangen, wenn ich mir nicht eingebildet hätte, das mit dpkg, quilt&Co... (quilt ist mal wieder so ganz böse hanky-cranky.. aber man lernt eben nie aus..)
Unter der alten URL zu laden.
(gzip ist fertig, habe ich jetzt aber weggelassen, weil das spielt zum testen glaube ich echt keine Rolle - wir reden von 10 vs 30 kB )

Makki

Index: rrdtool-1.3.1/src/rrd_tool.c
===================================================================
--- rrdtool-1.3.1.orig/src/rrd_tool.c	2010-11-12 21:14:36.000000000 +0100
+++ rrdtool-1.3.1/src/rrd_tool.c	2010-11-12 21:16:52.000000000 +0100
@@ -695,6 +695,30 @@
             free(ds_namv);
             free(data);
         }
+    } else if (strcmp("fetchj", argv[1]) == 0) {
+        time_t    start, end, ti;
+        unsigned long step, ds_cnt, i, ii;
+        rrd_value_t *data, *datai;
+        char    **ds_namv;
+        int written = 0;
+
+        if (rrd_fetch
+            (argc - 1, &argv[1], &start, &end, &step, &ds_cnt, &ds_namv,
+             &data) != -1) {
+            datai = data;
+            // printf("Content-Type: text/plain\n\n");
+            printf("[");
+            for (ti = start + step; ti <= end; ti += step) {
+                if (written==1)
+			printf(",");
+                printf("[%10lu,", ti);
+                for (ii = 0; ii < ds_cnt; ii++)
+                    printf(" %0.2f", *(datai++));
+                printf("]");
+                written = 1;
+            }
+            for (i = 0; i < ds_cnt; i++)
+                free(ds_namv[i]);
+            free(ds_namv);
+            free(data);
+            printf("]\n");
+        }
     } else if (strcmp("xport", argv[1]) == 0) {
         int       xxsize;
         unsigned long int j = 0;

[netzkind]

Hi makki,

schaut schon viel besser aus.
Jetzt muss ich nurnoch den Timestamp für die Ausgabe auf miliseconds umstellen (javascript erwartet das so), dann sollte das relativ bald rocken.

Da ich mein wiregate jetzt nicht mit einem vollen build-environment belasten will ... falls du das zufällig kurz umsetzen könntest, makki, dann wäre das klasse )

Grüße,
Julian