CometVisu - (interner) Beta-Test

[makki]

Jetzt muss ich mal dumm fragen: in der branch ist jetzt jquery 1.4.2 aber nicht die minified-version
Was soll nun ins Package:
- selber jsmin,
- die nicht-minified
- oder die von jquery angebotene minified-Version (1.4.2 natürlich) ?

Makki

[Chris M.]

Jetzt muss ich mal dumm fragen: in der branch ist jetzt jquery 1.4.2 aber nicht die minified-version
Was soll nun ins Package:
- selber jsmin,
- die nicht-minified
- oder die von jquery angebotene minified-Version (1.4.2 natürlich) ?

Makki

Die minified der 1.4.2 hatte ich auch die Schnelle nicht mehr bekommen und daher die normale zur minified erklärt. Das ist aber auch egal - denn das Skript soll nur auf das .min schauen und dumm machen. Dass es hier betrogen wird, ist egal.
Ziel hinter diesem Release ist es, den Release-Prozess zu üben. Wenn nämlich das nächste Release das für's öffentliche Beta ist, sollte der Prozess ja schon mal getestet worden sein.

(=> In's Package soll die .min die im inneren nicht minimized ist)

Nachtrag:
Wenn jemand sich die Mühe macht eine 1.4.2 in minimized zu finden, dann darf er die natürlich gerne im Branch drüberspielen...

[Chris M.]

Also, die Demo-Visu ist jetzt Release-Stand (würde ich dann auch so belassen)
Die trunk-Version hier (dito, ist zum testen/machen einfacher)

Du meinst das ./debian-Verzeichnis ? Macht IMHO wenig Sinn, weil das ist&wird niemals ansatzweise legal; ich befummle z.B. die config des Webservers, das ist illegal³ - aber nun notwendig damit halt "einfach" lüppt.. ein Teufelskreis..
Wer sich das wiregate-repo einträgt, der bekommt eine explizite Warnung, auf sf würde ich solche Pakete nicht stellen, denn wer sich von dort was installiert hat nunmal zu wissen, das er noch den Webserver konfigurieren muss.. das Backend ist nicht bestandteil des offiziellen bcusdk/eibd (derzeit auch gut so, weil teilw. schrott [-> hints zum segfault?])
Den Knoten wird man zwar irgendwann auflösen können, aber nicht von hier auf gleich..
Zum Backend: nach den Worten& berechtigten Bedenken von mkoegler würde ich daraus dann eh ein sep. eib-clients-cgi.deb o.ä. machen..

Ich meine ein Package, dass genau das installiert, was im Repository ist (+ minimized, etc.). Das Backend ist doch schon jetzt in einem anderen Package, oder?

Hat dieses Package denn irgendwelche Querwirkungen? Welche?
(Ich denke hier immernoch an andere Anwender, die kein WireGate und evtl. nicht mal einen KNX haben. Die müssen sich zwar selber um's Backend kümmern, aber den Client könnten die trotzdem per Package installieren.
Und das Anbieten im SF Download hat den Vorteil, dass Nicht-Debian-Nutzer sich dieses Package per alien trotzdem installieren können)

[makki]

Package ist draussen..
was tut:
- minify (s.u.)
- gzip mit cache (mod_compress war eh schon aktiv) von html,xml,js,ttf,css; das passiert ohne irgendwas "on the fly"
- funktionieren hoffentlich

Zum Rest später, hab Hunger

Makki


minify.sh

#!/bin/bash

for FILE in $( find ../var/www/visu/ ! -name *.min.js -name *.js ); do
	echo "Process $FILE"
	FILENAME=`basename $FILE`
	BASEPATH=`echo $FILE | sed 's/\.[^\.]*$//'`
	#echo "baspatch $BASEPATH"
	if [ ! -e $BASEPATH.min.js ]; then
		echo "NO minified for $FILE - creating"
		jsmin < $FILE > $BASEPATH.min.js
	fi
	# Now replace all occurences in include 
	#FIXME: look on path also!, be more careful
	sed -i s/$FILENAME\.js/$FILENAME\.min\.js/g ../var/www/visu/*.html
done

[vento66]

Hi Makki

Beim Installieren kommt noch ein Fehler bezüglich der geänderten visu_config.xml Und die schreibrechte für die visu_config.xml fehlen auch noch....

[makki]

Na, das zu erklären ohne mir selbst zu widersprechen wird gaanz schwierig

Also, kurzgesagt: das Package ist erstmal nur manuelles zusammengefummel, irgendwo zwischen Alpha&Beta, damits schnell und erträglich einfach geht..
Fürs nächste Package schreib ichs mal auf die Wunschliste, ein teufelskreis

Das Package tut im moment folgendes (was es "eigentlich" nicht darf)
- ln -s für eibread/write-cgi
- am Webserver rumfummeln
-> dieser Part hat ja eigentlich nichts mit der CometVisu zu tun sondern ist convinience-tuning und gehörte ins wg-patch, eib-clients-cgi etc.
- php's etc müssten in cgi-bin bzw. usr/share etc.pp.

Mein Vorschlag wäre eh erstmal ein .tar.gz des svn/branch-Stands.
Das minifien gehörte - kleiner Meinungswandel - eher in den Release-Prozess. Ich meinte ja eher, das ihr euch damit nicht aufhalten braucht.

@vento: ja, ist klar:

apt-get update; apt-get install cometvisu

Wie man das zukünftig handhabt ist noch offen, wenn die config mal keine strukturellen Änderungen mehr erfährt, gehört die eigentlich raus und so keine vorhanden - eine default angelegt.. (oder der Editor lässt sich mit einer leeren config starten ->?)

Makki

[vento66]

Danke makki. aber hatte es schon hinbekommen (langsam wirds mit mir und dem Pinguin )
@Chris jetzt kann man (ich) bei den slidern keine negativen Werte mehr eintragen es kommt immer die Meldung "min Value invalid"

[makki]

Zwecks der GA-config: ich denke es sollte beides gehen
- ich werde im nächsten Update den GA-Editor im Webmin reinnehmen, das man dort auch manuell eintragen kann
- für auf die schnelle ist es sicher schön, wenn man im Editor trotzdem einfach eine GA eingeben kann

Makki

[Chris M.]

Das Package tut im moment folgendes (was es "eigentlich" nicht darf)
- ln -s für eibread/write-cgi
- am Webserver rumfummeln
-> dieser Part hat ja eigentlich nichts mit der CometVisu zu tun sondern ist convinience-tuning und gehörte ins wg-patch, eib-clients-cgi etc.

Richtig, das gehört in ein anderes Package (und ein Depend in's CometVisu-Package)

- php's etc müssten in cgi-bin bzw. usr/share etc.pp.

Nö. PHP gehört nicht in cgi-bin, das gehört in das gleiche Verzeichnis wie die HTMLs.

Mein Vorschlag wäre eh erstmal ein .tar.gz des svn/branch-Stands.

Daran hatte ich auch gedacht - ein .deb sieht nur professioneller aus

Wie man das zukünftig handhabt ist noch offen, wenn die config mal keine strukturellen Änderungen mehr erfährt, gehört die eigentlich raus und so keine vorhanden - eine default angelegt.. (oder der Editor lässt sich mit einer leeren config starten ->?)

Eigentlich gehört die jetzt schon raus und nach /etc/ - nur das transparente (und sichere) Einblenden in den Browser zugreifbaren Bereich muss noch geklärt werden.
Das PHP zum Speichern kann das prinzipiell lösen - aber zum Lesen will ich kein zwingendes PHP (d.h. für'n Editor akzeptiere ich PHP, für die reine Visu will ich ohne auskommen).
Alternative ist natürlich ein Symlink. Aber ist der "legal"?

@Chris jetzt kann man (ich) bei den slidern keine negativen Werte mehr eintragen es kommt immer die Meldung "min Value invalid"

Du hast recht, das sehe ich auch. Das ist ein Thema vom Editor, nicht der Visu (-> Julian). Kann aber IHMO im trunk gelöst werden, das Release 0.5.1 kann so bleiben.

[makki]

Richtig, das gehört in ein anderes Package (und ein Depend in's CometVisu-Package)

Ja, dann haben wir aber dasselbe Problem: keiner kann was damit anfangen wenn ich einen Depend aufs wg-patch mache
Also nur die Basics, ein aktuelles wg-patch wird man in der Release-Version vorraussetzen dürfen..

Nö. PHP gehört nicht in cgi-bin, das gehört in das gleiche Verzeichnis wie die HTMLs.

Ich sage absolut nicht, das wir es aktuell jetzt dringend ändern sollten/müssen aber das stimmt so nicht ganz, kleines Beispiel
Ich sehe da halt aktuell keine Notwendigkeit, weil für die Funktion ist allem ja egal, wo das liegt

Alternative ist natürlich ein Symlink. Aber ist der "legal"?

Legal genug IMHO; hardcoded im PHP ist bestimmt noch legaler, aber wir können wegen mir gerne erstmal die Kirche im Dorf lassen

Edit: PS: genau das phpmyadmin hätte ich mir beim nächsten aber als Vorlage genommen

Makki

[Chris M.]

Ich sage absolut nicht, das wir es aktuell jetzt dringend ändern sollten/müssen aber das stimmt so nicht ganz, kleines Beispiel

Ich glaube das widerspricht mir nicht. Dieses Verzeichnis wird sicher dem DocumentRoot hinzugefügt (und das fällt nicht auf, da es halte keine puren HTML-Seiten gibt...)

Aber als Vorlage wird PHPMyAdmin vermutlich ziemlich gut passen.

[netzkind]

Ich sage absolut nicht, das wir es aktuell jetzt dringend ändern sollten/müssen aber das stimmt so nicht ganz, kleines Beispiel

Das ganze phpmyadmin-Verzeichnis wird dann aber über einen alias direkt unters Docroot gehängt damit es auch bei vorhandensein mehrerer vhosts überall erreichbar ist. In dem Fall also ein Schutz vor duplicate code und Plattenplatzverschwendung . So jedenfalls ist das übliche Vorgehen.
Von cgi-bin seh ich da nix, und kenne ich jetzt aus dem professionellen Umfeld (wir entwickeln praktisch 100% in PHP) so auch garnicht.

Ich bin da mit Chris' Meinung d'accord.

Grüße,
Julian

[netzkind]

jetzt kann man (ich) bei den slidern keine negativen Werte mehr eintragen es kommt immer die Meldung "min Value invalid"

Ist im SVN gefixt. War ein Fehler im regulären Ausdruck der Validierung, der negative Zahlen nicht als Zahlen akzeptiert hat

Grüße,
Julian

[makki]

Ich hab heute an dem "old-style" GA-Editor im Webmin gebastelt (und gleich julian's DPT-liste verwendet)
a) irgendwelche Einsprüche DPT_SubTypeName aus der eibga.conf ganz rauszuschmeissen - hat da eigentlich nichts verloren und wird auch nicht verwendet..
b) macht man das vielleicht gleich "New style", hipp in Ajax, einziges Problem: AA wäre dann zu lösen (muss man irgendwann aber eh)

Makki

[netzkind]

a) irgendwelche Einsprüche DPT_SubTypeName aus der eibga.conf ganz rauszuschmeissen - hat da eigentlich nichts verloren und wird auch nicht verwendet..

Das get_addresses.php nutzt sie nicht. Deshalb von mir kein Widerspruch.

b) macht man das vielleicht gleich "New style", hipp in Ajax, einziges Problem: AA wäre dann zu lösen (muss man irgendwann aber eh)

Was war gleich noch mal AA? Anarchist Academy? Anonyme Alkoholiker? Auswärtiges Amt? Mignon-Batterien?

Grüße,
Julian