Modifikationen an eibd und rrdtool upstream?

[greentux]

Alles zurück henfri. Das xport ist wesentlich mächtiger als das fetch. Das wird heute Abend nix mehr...

[greentux]

Das soll die Anwort sein henfri? Was macht der ganze Squeezeboxkram da?

[henfri]

Der eigentliche Kernpunkt: auf nem X-Core muss man sich wie du schreibst nur einen kleinen Wrapper bauen, der kann gerne ins CV-Packerl aufgenommen werden, fertig..
rrdtool 1.4+ ist wie du ja weisst keine Option, weil das (ich vermute wegen libgd vs. cairo) ist nochmal Faktor 10 langsamer, das geht garnicht..

Na, aber mit der CV ist doch nicht nur die Zielgruppe der kleinen Kisten anvisiert. Diejenigen (die Maintainer der kleinen Kisten, so wie du Makki) kommen mit dem ganzen Kram schon klar. Aber für alle anderen wäre es schon super, eine einfachere Lösung zu haben

Wie gesagt: Es geht nicht um Binaries (worum es geht hab ich ja mehrmals schon geschrieben).

Mal was anderes:
Gibt es in Distributionen wie Debian/Ubuntu, Suse und Co keine Möglichkeit zu sagen: Installier mir das Paket (geht) vom Source (geht, z.B. bei Debian, Gentoo) aber mit diesem Patch.diff.

Dann könnte man mit der CV einfach eine Diff für rrdtool und auch für den eibd (der aber ja kein Patch ist, sonder einfach zur zwei, drei *.c Dateien erstellt)

Gruß,
Hendrik

[henfri]

Henfri, ich habe gerade kein aktuelles rrdtool mit ner CV im Haus

Du könntest Dir ein

-rwxr-xr-x 1 user user     707 27. Dez 22:53 rrdfetch

ins cgi-bin legen.
Das könnte so aussehen:

Wow, das ging schnell!
Hab ich gemacht.

Antwort-HeaderFormatiert anzeigen
HTTP/1.1 200 OK Content-Type: application/json Content-Encoding: gzip Transfer-Encoding: chunked Date: Thu, 27 Dec 2012 22:09:05 GMT Server: lighttpd/1.4.28  Anfrage-HeaderQuelltext anzeigen
Accepttext/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Encodinggzip, deflateAccept-Languagede-de,de;q=0.8,en-us;q=0.5,en;q=0.3Connectionkeep-aliveCookieSqueezebox-expandPlayerControl=true;  Squeezebox-expanded-MY_MUSIC=0; Squeezebox-expanded-RADIO=0;  Squeezebox-expanded-PLUGIN_MY_APPS_MODULE_NAME=0; Squeezebox-expanded-FAVORITES=0; Squeezebox-expanded-PLUGINS=0; Squeezebox-player=00%3A04%3A20%3A17%3Ae7%3A08Host192.168.178.3User-AgentMozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0

Es scheint -was firebug angeht- kein Fehler aufzutauchen. Aber es wird auch kein Bild angezeigt.

Gruß,
Hendrik

[makki]

Makki, das Argument hast Du auf der rrdtool Liste aber nicht mehr gebracht. Insofern hatten die eigentlich ja keine Chance das doch upstream zu bringen. Die haben Deine Anforderung "ich will JSON direkt raushaben" eingebaut. Du hattest da ein fetch vorgeschlafen, die haben es mit xport gemacht. Dann war Ruhe.

Nun, ich hatte das schon explizit gesagt (u.a. auch in direkter Kommunikation) und Tobi Oetiker kennt sicher den Unterschied zwischen fetch und xport
Aber wenns nicht sein soll, hmm, dann darf ich auch mal Stur sein und es eben so machen wie ich es für richtiger halte..

Der eigentliche Kernpunkt: auf nem X-Core muss man sich wie du schreibst nur einen kleinen Wrapper bauen, der kann gerne ins CV-Packerl aufgenommen werden, fertig..
rrdtool 1.4+ ist wie du ja weisst keine Option, weil das (ich vermute wegen libgd vs. cairo) ist nochmal Faktor 10 langsamer, das geht garnicht..

Makki

[greentux]

Henfri, ich habe gerade kein aktuelles rrdtool mit ner CV im Haus

Du könntest Dir ein

-rwxr-xr-x 1 user user     707 27. Dez 22:53 rrdfetch

ins cgi-bin legen.
Das könnte so aussehen:

#!/bin/sh
#echo Content-Type: text/plain
echo Content-Type: application/json
echo Content-Encoding: gzip
echo

#rrdtool fetch /var/www/rrd/Luftfeuchte_Bad_knx5-2-79.rrd AVERAGE -s-24h
RRD=`echo "$QUERY_STRING" | sed -n 's/^.*rrd=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
DS=`echo "$QUERY_STRING" | sed -n 's/^.*ds=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
START=`echo "$QUERY_STRING" | sed -n 's/^.*start=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
END=`echo "$QUERY_STRING" | sed -n 's/^.*end=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`
RES=`echo "$QUERY_STRING" | sed -n 's/^.*res=\([^&]*\).*$/\1/p' | sed "s/%20/ /g"`

#FIXME: check path traversal

rrdtool xport -json /var/www/rrd/$RRD $DS -s$START -e$END -r$RES | gzip -c

Ich weiss nicht, ob die Parameter für xport den fetch entsprechen. Laut Doku rrdtool könnte es so sein.
Das Script oben ist das vom WG, ausser einer kleiner Anpassung in der letzten Zeile.
Damit "könnte" Diagramme schon gehen.
Wenn auch mit Performance und Paketoverhead...

[henfri]

(eibd)
Dann nimmste die perfekt vorgekauten Pakete und baust ihn dir, wie steht oben schon.. Läuft ohne jeglichen Fehler durch..

Beim Eibd mag das sein, da mag ich was verbockt haben.
Aber beim rrdtool sind wir ja wohl beide gescheitert.

Dennoch&nochmal: Was spricht dagegen, die zwei Miniprogramme als *.c, makefile&co mitzuliefern?

Sorry, wenn Performance "wurscht" ist, kann man sich easy ein py/bash/perl bauen das rrdfetch und eibread/write entspr. "wrapped" - das posten nicht vergessen - nicht mein Job, ich habs gern in klein & schnell..

Das wäre ja eine Option: dieses Skript könnte dann mit der CV mitgeliefert werden. Wer mehr Performance braucht kann dann Entscheiden, ob er 1mal 5h mit rrdtool, ruby&Co Zeit verbringt, oder täglich 0.7s an der Visu für den Rest seines Lebens (ich sehe ein, dass 0.7 s sehr störend sein können!)

Gruß,
Hendrik

[greentux]

Makki, das Argument hast Du auf der rrdtool Liste aber nicht mehr gebracht. Insofern hatten die eigentlich ja keine Chance das doch upstream zu bringen. Die haben Deine Anforderung "ich will JSON direkt raushaben" eingebaut. Du hattest da ein fetch vorgeschlafen, die haben es mit xport gemacht. Dann war Ruhe.

Also gibts jetzt nen eigenen Patch und basta. Bitte dann nicht dauernd rummäkeln, das der Upstream Kram so "schlecht" ist.

[makki]

Upstream ists ja gekommen. Nicht unbedingt als fetchj (neue Funktion), sondern als Anpassung von xport (neben xml nun auch json):
..

Ich weiss, 1.3.1 hat so seine Vorteile auf dem WG. Aber was spricht dagegen, die CV das mit xport machen zu lassen, statt fetchj?
xport könntest Du ja in 1.3.x reinpatchen. Auf neueren Plattformen wäre kein Patch notwendig.

Was dagegen spricht, ist das wir fetch (definierte Datenmenge/Auflösung, die grosse Stärke des rrdtool!) haben wollen nicht xport!
Also mal ein paar Zahlen:

wiregate1:~# time rrdtool xport DEF:ds0=/var/www/rrd/28.0936EC010000_temp.rrd:value:AVERAGE XPORT:ds0 | wc -c
16430

real	0m0.128s
user	0m0.012s
sys	0m0.020s

wiregate1:~# time rrdtool fetchj /var/www/rrd/28.0936EC010000_temp.rrd AVERAGE | wc -c
7512

real	0m0.070s
user	0m0.016s
sys	0m0.008s

Übersetzt: xport dauert 128ms vs. 70ms und produziert 16kb vs 7,5kb an Daten (die über die Leitung müssen, geparsed etc..)
Das sind rund 140% bzw. >200%
Jetzt mag man sagen: das spielt ja keine Rolle, kauf ich mir halt nen neuen Quadcore, wenn der Programmierer nicht mit Resourcen umgehen kann
So tickts hier aber nicht und diese Option ist keine, denn Resourcen sind beschränkt (das nächste WG wird eher kleiner als fetter), Strom kostet Geld und diese denke finde ich auch völlig falsch..

Man kanns nicht allen recht machen, es soll schnell sein (das ist es), gleichzeitig aber perfekt portabel (das ist es, auch, läuft auf einem OpenWRT mit 32MB RAM und 8MB Flash!) und dann noch DAU-sicher, damit mans auf dem neuesten Susi/64 ohne jegliches Wissen kompilieren kann -> da beginnt nun der Interessens-konflikt..

Und wenn ich die auf meinem Ubuntu installieren will?

(eibd)
Dann nimmste die perfekt vorgekauten Pakete und baust ihn dir, wie steht oben schon.. Läuft ohne jeglichen Fehler durch..

Sorry, wenn Performance "wurscht" ist, kann man sich easy ein py/bash/perl bauen das rrdfetch und eibread/write entspr. "wrapped" - das posten nicht vergessen - nicht mein Job, ich habs gern in klein & schnell..

Edit: nur noch am Rande, worums geht: 60ms sind verdammt wenig, wurscht, aber wenn man auf einer gewöhnlichen Visu 200 Diagramme hat, sind das mal flockige 200*60ms, also 12 verdammt lange Sekunden Strafzeit beim aufrufen der Visu - nur dafür!
Edit2: @greentux: natürlich kann man das hinbekommen: man patcht einfach das fetchj (ist schön fein säuberlich mit Quilt im Packerl) ins rrdtool 1.4

Makki

[greentux]

ich denke immer noch, man müsste das sauber hinbekommen. Ich bin allerdings kein autoconf Profi, der sitzt im Büro allerdings mir gegenüber. Da werde ich mal am 3.1. direkt mal nachfragen.

[henfri]

Auf meinem WG sind die im eibd-clients Paket mit drin.

Und wenn ich die auf meinem Ubuntu installieren will?

Gruß,
Hendrik

[greentux]

Auf meinem WG sind die im eibd-clients Paket mit drin.

[henfri]

Rum rrdtool kann ich nichts sagen, mit dem habe ich mich nie beschäftigt.

Wer wäre den ein guter Ansprechpartner?

Der eibd braucht kein Patch und eine "DLL-Hell" gibt's da in keinster Weise. Wahrscheinlich funktioniert eibread-cgi/eibwrite-cgi auch noch mit einem eibd-0.0.4 oder älter...

Na, das Problem hatte ich mit rrdtool, das stimmt.

Einfach mitliefern mit der CV ist nicht. Die CV sind statische Dateien, die ein Web-Server ausliefert - egal auf was und wie der läuft.
eibread-cgi und eibwrite-cgi sind dagegen Programme, die für eine Zielplattform kompiliert werden muss: 32 oder 64 bit? x86, ARM, Sparc, MIPS, PowerPC, ...? Linux? Windows? OpenBSD? ... - alles eigene Kompilate. Sollen die alle mit der CV mit kommen?!?

Nein, wie hatte ich ja bereits oben gesagt: als Source mit Instruktionen zum Kompilieren. Aber eben einzig eibread-cgi&co.

Das Zitat ganz oben in meinem Eingangspost ("eibread/write-cgi are part of a modified eibd-clients package here:") suggeriert(e) mir, dass ich eben den eibd aus diesem Repo nutzen muss.

Und jetzt kommts noch härter: eibread-cgi und eibwrite-cgi sind gerade mal eine mögliche Implementierung des Backends für eine Umgebung.

Na komm. Der User möchte doch einfach nur die CV nutzen. Viele werden den eibd haben oder per Paket installieren können für ihre Distribution mit allen Abhängigkeiten usw usw.

Wenn jetzt noch die obigen *.c files inklusive Makefile oder ähnlichem geliefert würden, könnte der arme Dau mit einem make oder ./configure &&make&& make install diese mini-Programme installieren und könnte so ohne weiteres/mit sehr kleinem Aufwand ein Backend erstellen.

Wenn, dann muss eibread-cgi/eibwrite-cgi als eigenes Paket verteilt werden.

Für 32 oder 64 bit? x86, ARM, Sparc, MIPS, PowerPC, ...? Linux? Windows? OpenBSD? ... Für Suse, Für Debian, ... ...

Ich verstehe echt nicht, was einem Verzeichniss "Backend" mit den *.c, Makefile und co schlimm wäre

Gruß,
Hendrik

[Chris M.]

Klar, ein eigenes Paket wäre auch eine Lösung, und tatsächlich wohl die sauberste. (Hm, ist es nicht sogar aktuell ein eigenes Paket).

.....

[greentux]

Naja Chris, also es gibt garantiert mehr Leute, die eibd nutzen als Leute, die CV nutzen. Von daher denke ich, das die Backends doch eher zur CV gehören, auch wenn Du Dich selber primär mit dem Frontend beschäftigst, oder?
Wie gesagt, gehen die read und write auch als php/python und damit sind wir die Architektur schon ein wenig los... Das rrdfetch ist nur ein Script. Mehr brauchts eigentlich nicht.
Ich denke ein Paket für die CV und eines für nen jeweiligen Konnektor.

Die Logikengine die Du meinst, ist dann sicher ein weiteres Paket...