CometVisu - (interner) Beta-Test

[Chris M.]

ich bekomme diesen Fehler beim SVN Update.
Was mache ich falsch ?

Ich denke nichts - Du hast einfach einen Konflikt zwischen der lokal bei Dir veränderten Config-Datei und der im Repository. D.h. Du musst nun wohl sagen welche Version Du behalten willst.

[manu241]

Fehler bei SVN Update

Hallo,

ich bekomme diesen Fehler beim SVN Update.
Was mache ich falsch ?

Manuel

[makki]

ich hab mal einen Stand der Diagramme ins SVN gepackt

Ist sich online -> Temperaturen

(inkl. den Inline-Frames übrigens -> unter Wetter)

Noch nicht 100% perfekt wie man sieht, aber dem geneigten Beobachter möchte ich nochmal mit auf den Weg geben: mit wie wenig Aufwand & in welch fast schon verboten krimineller Geschwindigkeit das ganze passiert! Die Grafik wird real beim Klick gezeichnet und die Daten in Echtzeit, sekundengenau abgeholt
Was da jetzt hinten dran hängt ist wirklich ein stinknormales WG (ok, die 3x-Eth Version aber selbe CPU etc., nebenbei ists noch mein Internet-Router und etc.pp. drauf..)

Für letzteres fehlt mir das Layout wie man das optisch umsetzen könnte mit Buttons o.ä.

Wie glaube ich schon gesagt: ich denke hier an Tag/Woche/Monat/Jahr-Button im Popup.
In V1.5 optimalerweise konfigurierbar, brauchen 95% aber IMHO garnicht.
Und dazu den aktuellen Wert im Klartext, also quasi eine Mischung aus Info & diagram.
(ich schreibe das bewusst nicht in den SF-Tracker, weil ihr lest das, lasst es einfliessen und macht es oder eben nicht, wie ihr meint; IMHO auch gut so..)

Das aussehen der Buttons ist ja glaube ich eher eine geschichte des designs, oder.. In discreet halt hellgrau auf schwarz und in pure orange auf hellgrau

Makki

P.S.: Ganz strange: momentan will das im FF hier nur noch, wenn ich 1x den Firebug aufmache (?)! Ich wechsel morgen mal testweise Browser&OS

Da merkt man, dass wir hier an der vordersten Web-Entwicklungs-Front sind...

Ja, ich glaube das vermuteten wir aber alle vorher, das derlei Dinge aufpoppen werden
Es geht allen unkenrufen zum trotz sehr gut voran und ich bin mir trotzdem sicher, das es auf dem richtigen Weg ist.
Wenns allzu easy wäre, hätten das alle Flash&App-verliebten Mädchen ja auch vorher schon gleich in richtig gemacht
Vor 1-2 jahren musste ich mich noch halb auslachen lassen, das so ein Slider im Browser überhaupt machbar wäre, das Gegenteil wurde bewiesen, es geht nur noch um ein paardutzend details
Aber der richtige Weg ist nicht zwangsweise der einfachste, am Ende zählt nur das Ergebniss.

[Chris M.]

@Chris: für eine Variante der Diagramme hab ich deine Popups gebraucht. Ich hab deinen Code deshalb etwas angepasst, damit man ins Popup jQuery-Objekte injecten kann, und man das Popup wieder schließen kann (bislang: einfach click ins popup). Zusätzlich das Problem mit dem halbtransparenten Inhalt gelöst und dass es bislang nur error-Popups gab. Bitte änder den Popup-Code so wie du es für nötig hältst, meine Änderungen sind da sicher nicht des Meisters letzte Worte

Es ist durchaus Ziel gewesen, dem Popup ein jQuery als Content mitgeben zu können. Werd's mir bald ansehen...
Die Popups sind "experimentell" gekennzeichnet, da ich einfach gestern Abend meine Entwicklungsversion sichern wollte. Aber anscheinend hat sich's gelohnt, denn Julian scheint das Problem mit dem "error" gefunden und gefixt zu haben (laut SVN - mein FireBug hat das letzte apt-get update nicht überlebt )
=> Bitte die Popups aktuell nur verwenden, wenn ihr wisst, was ihr tut - die können sich noch deutlich wandeln, bis zur richtigen Freigabe.

Kurze Erklärung für alle die schon im SVN testen wollen:
Neu sind type "diagram_inline" und "diagram_popup". Letzteres ist mein persönlicher Favorit. Im XML muss als neues Plugin "diagram" eingetragen werden damit die neuen types im Editor auftauchen.

Mein Ziel ist, dass jedes Widget (und damit auch jedes mitgelieferte Plugin) in der im Paket enthaltenen visu_config.xml enthalten ist - so dass man schon man ein Beispiel hat, wie das aussehen kann. D.h. am besten fügst Du das dort auch noch mit ein.
Vor der öffentlichen Beta müssen wir die Konfig dann mal aufräumen und strukturieren. Da können wir auch gerne die GAs verwenden, die für Makkis Demo-Server gelten.

Ja, Chris, ist werds auch bei SF eintragen

So ist's brav

[netzkind]

Muss. entwickeln... kann. nicht. schreiben.

So, mein Kopf brummt:
ich hab mal einen Stand der Diagramme ins SVN gepackt, das ist aber a) rfc und b) bislang optisch nur mit discreet erträglich (Farben sind aktuell hardcodiert!) und c) kann man noch nicht in der Visu zwischen verschiedenen Zeiträumen switchen.
Für letzteres fehlt mir das Layout wie man das optisch umsetzen könnte mit Buttons o.ä.

@Chris: für eine Variante der Diagramme hab ich deine Popups gebraucht. Ich hab deinen Code deshalb etwas angepasst, damit man ins Popup jQuery-Objekte injecten kann, und man das Popup wieder schließen kann (bislang: einfach click ins popup). Zusätzlich das Problem mit dem halbtransparenten Inhalt gelöst und dass es bislang nur error-Popups gab. Bitte änder den Popup-Code so wie du es für nötig hältst, meine Änderungen sind da sicher nicht des Meisters letzte Worte

Kurze Erklärung für alle die schon im SVN testen wollen:
Neu sind type "diagram_inline" und "diagram_popup". Letzteres ist mein persönlicher Favorit. Im XML muss als neues Plugin "diagram" eingetragen werden damit die neuen types im Editor auftauchen.

Konfiguration:
rrd: Name des RRD-Files ohne suffix
refresh: wenn das Diagramm alle X Sekunden aktualisiert werden soll - hier X eintragen
width, height: optional, CSS-artig (px, %, em, pt, km, ...)
unit: Einheit wie °C oder kWh für die Achsenbeschriftung
series: day, week, month oder year eingeben

Dabei sind mir noch zwei Dinge für den Editor eingefallen:
- vom widget vorgegebene select-Liste statt Eingabefeld
- vom widget vorgegebene Hilfetexte zu den Eingaben

Ja, Chris, ist werds auch bei SF eintragen

Grüße,
Julian

[Chris M.]

Wenn ich das richtig beobachte, dann passiert das bei allen Dateien die per jQuery zur Laufzeit in den DOM injected werden - ich hab hier das gleiche Problem mit JS-Code.

Genau so schlimm, die nachträglich geladenen JS werden im FireBug nicht angezeigt - angeblich ein FF Bug.
Da merkt man, dass wir hier an der vordersten Web-Entwicklungs-Front sind...

[makki]

Wenn ich das richtig beobachte, dann passiert das bei allen Dateien die per jQuery zur Laufzeit in den DOM injected werden - ich hab hier das gleiche Problem mit JS-Code.

Da sollten wir noch dahinter kommen, ich teste morgen auch nochmal..

Muss. entwickeln... kann. nicht. schreiben.

gut so, weitermachen

Was mich aktuell wesentlich mehr ausgebremst, ist dass die CSS manchmal ums Verrecken nicht neu geladen wird

Unterstützt der lighty eigentlich .htaccess o.ä. um in einem Verzeichnis die HTTP-Cache-Dauer auf no-cache zu setzen?

Ja, ich fürchte aber das löst das Problem nicht wirklich. Es ist ja jetzt schon so, das (unter manueller beobachtung!) der browser mit dem richtigen Zeitstempel nachfrägt und der server bei geänderten Files das neuere ausliefert. Aber eben scheinbar nicht immer, nur immer wenn ich das suchen anfange dann rutschts plötzlich.. Ich mach das morgen nochmal ohne Firebug und dafür mit wireshark, um das messergebniss nicht zu beeinflussen..

An so etwas hatte ich nicht gedacht - aber das wäre natürlich durchaus denkbar.

Ähm, das ist aktuell aber so

Mit dem l(ogin) hätte ich die Credentials mitgeschickt - mit denen kann der Server prüfen ob der User auf die entsprechenden GAs zugreifen darf.

Naja, das Problem ist, in meiner Welt kommt der ggfs. garnicht dazu, hier die credentials mitzuschicken, weil er vorher an der HTTP-Auth vorbei muss
Eigenerfindungen halte ich an der Stelle der Authentisierung für garnicht zielführend; keine, Basic, Zertifikate, OTP-Token, anything goes und das will ich nicht wirklich im Backend alles nochmal nachstricken und anzufangen eine Userdatenbank zu schreiben; das können lighty&apache schon verdammt gut..
Defaultmässig stehe ich intern trotzdem auf "offen"/ohne (RFC1918-IP's), was man unter einen Hut bringen muss.

Die Authorisierung danach ist was anderes, da bin ich noch am grübeln, vor allem wie man das komfortabel verpackt.
Das beste und einfachste ist aber vermutlich: auf den REMOTE_USER gehen. + prüfen ob config lesbar/schreibbar; das muss ich aber erstmal herausfinden ob/wie das mit einem (anderen cgi) zu prüfen geht, eine Übermittlung, welche config die Visu hat/nutzt erscheint mir daher sinvoll.
Genauso geht natürlich index.php statt .html und l(ogin), das ist aber gehüpft wie gehoppelt..
Die jetzige Konstellation mit index.html und login (der eigentlich keiner ist) ist halt IMHO schöner, um ggfs. auch "schöne" Fehlermeldungen im Client anzeigen zu können usw

Makki

[netzkind]

Ich konnte bisher nur beobachten, dass wenn FireBug aktiv ist, der Reload mancher JS nicht immer durchgeführt wird.
Was mich aktuell wesentlich mehr ausgebremst, ist dass die CSS manchmal ums Verrecken nicht neu geladen wird

Wenn ich das richtig beobachte, dann passiert das bei allen Dateien die per jQuery zur Laufzeit in den DOM injected werden - ich hab hier das gleiche Problem mit JS-Code.

Grüße,
Julian

PS:
@makki: nein, hat mir nicht die Sprache verschlagen. Muss. entwickeln... kann. nicht. schreiben.

[Chris M.]

Ich denk mir halt, lieber so manches erstmal zärtlich zur Diskussion zu stellen, weil ein 100x Wunschkonzert mit unrealistischem Stoff bringts auch ned.. Welchen Aufwand/Nutzen was bringt, tut man sich schwer zu beurteilen..

Ich will hier auch keine Diskussion unterbinden - nur hab ich keine Lust nochmal 275 Postings durchzupflügen damit keine Wünsche et al. verloren gehen.
=> Am besten hier und dort schreiben...

Ich muss darauf nochmal zurückkommen: Thema Browser-Cache nach Update: heute wieder nach svn up: schwarzer schirm im FF (diesmal aber bewusst)
Irgendwann stunden später zufällig den Firebug angeworfen, plötzlich gehts (ohne Cache leeren oder STRG+F5!)
Wenn ich hier manuell teste und z.B. nur ein js ändere, wird das aber beim normalen laden ganz sauber neu geholt; jegliche Idee wie man das im Zweifelsfall "hinprügeln" kann?
Ich glaube weder der Webserver noch der Browser machen hier bei manueller Aufsicht was falsch, vermutlich aber dann doch ein schlichter Bug im Browser?!

Ich konnte bisher nur beobachten, dass wenn FireBug aktiv ist, der Reload mancher JS nicht immer durchgeführt wird.
Was mich aktuell wesentlich mehr ausgebremst, ist dass die CSS manchmal ums Verrecken nicht neu geladen wird

Unterstützt der lighty eigentlich .htaccess o.ä. um in einem Verzeichnis die HTTP-Cache-Dauer auf no-cache zu setzen?
(Bei'm Releasten Paket macht das Cachen aber durchaus Sinn, d.h. ich würde nur gern die SVN Version hier etwas "modifizieren")

Zwecks Session&config: die Endfassung ist jetzt visu/index.html?config=xyz um eine andere als die default visu_config.xml zu holen, richtig?

An so etwas hatte ich nicht gedacht - aber das wäre natürlich durchaus denkbar.

-> Dann wäre es für die Authz auf GA-Ebene glaube ich schön, wenn der Visuclient config=xyz noch beim l(ogin) mitgeben würde.
(ja, es bleibt hier eine theoretisch "Lücke" weil die Visu könnte beim login natürlich eine config anfordern, auf die es lt. remote_user garkeinen Zugriff hat; das kann man aber später immernoch im login.php/whatever abfangen und es ist wirklich eher theoretisch, weil er dafür erstmal grundsätzlich zugriff braucht..)

Mit dem l(ogin) hätte ich die Credentials mitgeschickt - mit denen kann der Server prüfen ob der User auf die entsprechenden GAs zugreifen darf. Diesen Mechanismus könnte man natürlich erweitern um die Übertragung der Config abzusichern.

[makki]

Der Wunschzettel steht auf SourceForge - andere Wünsche können nicht berücksichtigt werden...

Schon verstanden
Ich denk mir halt, lieber so manches erstmal zärtlich zur Diskussion zu stellen, weil ein 100x Wunschkonzert mit unrealistischem Stoff bringts auch ned.. Welchen Aufwand/Nutzen was bringt, tut man sich schwer zu beurteilen..

Ich muss darauf nochmal zurückkommen: Thema Browser-Cache nach Update: heute wieder nach svn up: schwarzer schirm im FF (diesmal aber bewusst)
Irgendwann stunden später zufällig den Firebug angeworfen, plötzlich gehts (ohne Cache leeren oder STRG+F5!)
Wenn ich hier manuell teste und z.B. nur ein js ändere, wird das aber beim normalen laden ganz sauber neu geholt; jegliche Idee wie man das im Zweifelsfall "hinprügeln" kann?
Ich glaube weder der Webserver noch der Browser machen hier bei manueller Aufsicht was falsch, vermutlich aber dann doch ein schlichter Bug im Browser?!


Zwecks Session&config: die Endfassung ist jetzt visu/index.html?config=xyz um eine andere als die default visu_config.xml zu holen, richtig?
-> Dann wäre es für die Authz auf GA-Ebene glaube ich schön, wenn der Visuclient config=xyz noch beim l(ogin) mitgeben würde.
(ja, es bleibt hier eine theoretisch "Lücke" weil die Visu könnte beim login natürlich eine config anfordern, auf die es lt. remote_user garkeinen Zugriff hat; das kann man aber später immernoch im login.php/whatever abfangen und es ist wirklich eher theoretisch, weil er dafür erstmal grundsätzlich zugriff braucht..)

Makki

[Bodo]

Voll coool ey. Danke

[Chris M.]

Apropos <Wunschkonzert>

Der Wunschzettel steht auf SourceForge - andere Wünsche können nicht berücksichtigt werden...

Könnte man eigentlich auch Popups vorsehen, die entweder sticky sind oder einfach nach einstellbarer Zeit wieder verschwinden?

Wie gut dass es da schon den Eintrag SourceForge.net: Open Automation: Detail: 3109762 - Info / Warning / Error Pop-Up gibt.

Gestern Abend habe ich übrigens die erste, noch experimentelle Version eingecheckt (Revision: 183), d.h. solche Wünsche über bestimmtes Verhalten der Popups kommen gerade zur rechten Zeit

[Bodo]

Hoi an's Team

Apropos <Wunschkonzert>

Könnte man eigentlich auch Popups vorsehen, die entweder sticky sind oder einfach nach einstellbarer Zeit wieder verschwinden?

[makki]

Authz

Wahrscheinlich habe ich mich mal wieder konfus ausgedrückt...

Ich werds verstehen wenns fertig ist, das reicht ja

Gerne - da darfst Du Dich jetzt austoben.

Naja, derzeit kann man mir hier direkt das Licht (und mehr wenn man weiss wie) ausknipsen, andererseits finde ich eine "echte" Demo aber immer schöner & vor allem glaubwürdiger.

Die meisten technischen & krypto-Details mal weggelassen (ich bin mal so frech und unterstelle das als richtig ):
a) die CometVisu bekommt beim l(ogin) einen "Token" (=SESSION?) und zeigt diesen bei jedem read/write einfach mit vor. Das ist nicht 100% was der paranoide in mir verlangt, aber ich will vermeiden das bei jedem Request komplexe Algorithmen abgefahren werden müssen (vielleicht unbegründet die Perf-Angst..)
b) dieser Token muss natürlich irgendwann ablaufen - entweder zeitbasiert, 1-4h oder so und die ablaufzeit wird mitgeliefert - vermutlich mehr Aufwand im Client. (+ möglicher server-restart etc.)
Oder r/w liefern irgendwann einfach "Nein" in Form eines bestimmten json-Feldes und der Client macht einen erneuten l(ogin)


Die "erlaubten" GA's würde ich beim login jetzt erstmal ganz stumpf&ohne Kunstwerk aus der gezogenen config_..xml holen (davor ist nämlich ggfs. später die Authentisierung - wer editieren darf, bestimmt ganz einfach wer was sehen lesen/schreiben kann).
info=darf lesen, dim=schreiben usw., vielleicht könnte man das noch in dem XSD unterbringen (da versth ich jetzt wieder weniger von..)
-> dafür müsste man aber evtl. das login um den _config-Namen erweitern (?)
Ich würde hier aber gerne irgendwo einen Strich ziehen zwischen selbergebaut & Webserver liefert die config einfach nicht, wenn der User nicht passt. Vielleicht ist hier auch ein cgi sinnvoller, das zusammen mit dem l(ogin) die visu_config ausliefert.

Andererseits sollte es nämlich IMHO auch dringend ohne Authentisierung ganz einfach funktionieren - so wie jetzt auch - weil im LAN und damit in den meisten Fällen braucht diese ganze Security-Funktions-Verhinderung kaum einer


Jedenfalls, das login macht man dann irgendwie nen hübschen hash von, speichert sich das temporär im Filesystem, da will ich aber noch ein paar Tests machen - schliesslich soll es beim read auf keinen Fall bremsen.


Den Rest macht der Webserver mit Basic/Zertifikats-Authentisierung, SSL & Co.
Das Gesamtkonzept ist da aber (in komfortabel!) ehrlichgesagt noch etwas unscharf, letztlich wird es aber denke ich darauf hinauslaufen, welche Rechte der REMOTE_USER im Webserver auf die jeweilige config.xml hat.

Makki

[Chris M.]

Das ist die grosse Frage, wierum man das Pferd aufzäumt.
Varianten sind natürlich str/int/float oder eben DPT;
Aber die DPTs haben den grossen Vorteil, das das - wenn es denn konsequent überall umgesetzt (wäre/würde) nicht nur einen Wert enthält sondern auch bereits definiert ist was da & welcher Einheit drinsteht (°C, mA, Bananen,...)

Wahrscheinlich habe ich mich mal wieder konfus ausgedrückt... Mein Ziel ist von Einheiten weg zu gehen und zu Transformations-Formeln hin zu gehen. Das Ergebnis einer Transformation ist immer ein JavaScript nativer Wert (also ein int, float oder string) mit optional einer Einheit.

Grundsätzlich finde ich den Gedanken mit den DPT's ja nicht schlecht, das ist auch IMHO nicht grundlegen (zu) KNX-spezifisch.

Die sind schon gut und bleiben deswegen bestehen. Nur setze ich einen Level tiefer an und abstrahiere das zugrunde liegende System weg.

Ok, wir können die 7 Zeilen löschen aber das ist ja jetzt schon so, wenn es kein d gibt ist es rohmaterial, das so 1:1 durchgereicht wird (solange es ein A_Groupvalue_Write ist)
Da würde ja jetzt nicht gesprengt wenn ich Dich richtig verstanden hab?

War mir nicht klar, dass das jetzt schon geht. Dann wird der Übergang schmerzfrei gehen

Viel spannender finde ich in dem Kontext mal langsam a bisserl Autorisierung, insbesondere in write-backend einzustricken..

Gerne - da darfst Du Dich jetzt austoben. IIRC hattest Du da ja schon ein paar Ideen zu.
Im Zweifel einfach mal das Konzept schreiben, Client-Seite würde ich implementieren, Server/Backend liegt eh bei Dir