CometVisu - (interner) Beta-Test

[makki]

rrdfetch

Was machen wir eigentlich mit dem Kind? Ist cool und schnell, alles wunderbar. Aber genau genommen ein fork vom rrdtool

Upstream besteht ein gewisser Wille (ich hatte das auch schon auf rrd-devel gepostet), allerdings eher in richtung xport statt fetch (20fache Datenmenge zu übertragen..) aber das würde wenn nur in die (10x langsamere wegen irgendwelcher lustiger libcairo-schiessmichtot und daher IMHO keine Option) v1.4 einfliessen, nicht in die 1.3.1 die man in Debian stable grad so hernimmt.

Ich hab glaube ich keinen Schmerz damit diese "Variante" von rrdtool 1.3.1 zu verteilen, aber das ist halt schon wieder eine *ziemlich* spezielle Geschichte, von der die Cometvisu dann auch abhängt...

Wie steht ihr (Chris, Julian) dazu? SuperSonderlocke machen und dafür klein,schön,schnell oder? Jedenfalls könnte man ein billiges shellscript wie in v0.1 machen das mit dem orginal rrdtool funzt, aber dann ists halt eher a***langsam und macht IMHO unterm Strich keinen Spass..

Das ist Fluch und Segen von OSS zugleich, wenn einem was nicht passt ändert man's halt (hier ja nur das ausgabeformat)

Makki

P.S.: Wenn der liebe Gott mal gnädig ist, bekomme ich das auch noch hin, den Wert vor dem Popup anzuzeigen

[Chris M.]

Was machen wir eigentlich mit dem Kind?
[...]
Ich hab glaube ich keinen Schmerz damit diese "Variante" von rrdtool 1.3.1 zu verteilen, aber das ist halt schon wieder eine *ziemlich* spezielle Geschichte, von der die Cometvisu dann auch abhängt...

Die CometVisu hängt ja nicht davon ab - das tut lediglich nur das diagram-Plugin. Und die Dependencies der Plugins sind mir relativ egal.(*)

D.h. ich schlage vor, weiterhin bei dem Fork zu bleiben, wenn es uns wirklich was bringt.

Diesen Fork sehe ich allerdings nicht als Bestandteil der CometVisu - darf aber natürlich gerne im SF mit veröffentlicht werden, damit jeder leichten Zugriff drauf hat.


--
(*) Man darf auch gerne ein Plugin schreiben, dass Werte aus dem HS ausliest. Das Plugin würde ich natürlich auch im SVN sehen - ohne dass wir einen HS mitliefern würden...

[makki]

wenn es uns wirklich was bringt.

Naja, daher die Frage, ob ich da jetzt vielleicht zu engstirnig ticke 20-30ms statt 500-2000 auf lausiger HW (also keine Core i5-7) finde ich schon als "bringt was"

Diesen Fork sehe ich allerdings nicht als Bestandteil der CometVisu - darf aber natürlich gerne im SF mit veröffentlicht werden

Denke nicht das das wirklich notwendig ist, ich denke ich packe das - natürlich inkl. Source .deb ins repo - wir sprechen hier echt von einem depperten 10-Zeiler-Patch, wovon 7 Zeilen kopiert sind trotzdem..

(*) Man darf auch gerne ein Plugin schreiben, dass Werte aus dem HS ausliest.

Hmm, das mag - allein aus der Not - passieren können.. Anderes Thema

Makki

[Chris M.]

Naja, daher die Frage, ob ich da jetzt vielleicht zu engstirnig ticke 20-30ms statt 500-2000 auf lausiger HW (also keine Core i5-7) finde ich schon als "bringt was"

Finde ich auch.

Denke nicht das das wirklich notwendig ist, ich denke ich packe das - natürlich inkl. Source .deb ins repo

Klar, das geht auch.

Wir sollten nur der diagram-Plugin-Doku einen Hinweis hinzufügen, wo der nicht eingeweihte sieht, wie er dieses Tool bekommt.

[netzkind]

Ich saß jetzt wieder mal ein paar Stunden am Editor, aber irgendwie hab ich noch nicht den Weg gefunden auf dem man das so umsetzen könnte dass es dauerhaft und allgemeingültig funktioniert.
Entweder man geht jetzt den Scrum-Weg (Eliminate waste - also nicht allgemeingültig programmieren wenn das kein Erfordernis ist) - oder wir wechseln mit dem Format der Config von XML auf JSON.

Oder, wenn ich das so schreibe: wir wandeln das XML direkt nach dem Ladezeitpunkt in echte Javascript-Objekte um und arbeiten mit denen statt per jQuery auf DOM-Objekte zuzugreifen (major PITA)

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Grüße,
Julian

[Chris M.]

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Auch ein Monolog kann da manchmal hilfreich sein

Evtl. hilft da auch die Antwort bei Stack Overflow auf die Frage, die ich mir beim Logik Editor gestellt habe: Where to place interactive objects in JavaScript?

Allgemeingültig sollte die Lösung insofern sein, dass man mit "geringem" Aufwand an "nur einer Stelle" neue Widgets hinzufügen kann (sowohl offizielle, als auch private und Plugins). Außerdem sollten die Widgets leicht erweiterbar sein - z.B. in naher Zukunft um x und y Koordinaten (für die 2D Visu), als auch um ein z bald darauf.
Noch allgemeiner braucht es IMHO nicht zu sein.

Nur zur Sicherheit: die Meta-Infos wie die "attributes" in der aktuellen Struktur habe ich bewusst noch nicht auf die neuen Gegebenheiten angepasst - da die ja von der Editor-Implementierung abhängen.

[makki]

oder wir wechseln mit dem Format der Config von XML auf JSON.

CSV oder .ini stand nicht auf der Liste ? Sorry, war nur ein Treppenwitz
Ich denke: solange es einen Editor gibt ist das relativ egal, ob das hinten oder vorne als XML, JSON, SQL oder sonstwas abgelegt wird. Wer programmatisch rangeht kommt mit all dem klar, dem Anwender ist das eh wurscht..

Beim "semi-power-user" scheiden sich dann aber die Geister, deswegen mag und mochte ich XML ehrlichgesagt noch nie, weil das ist erstmal totale geekshow, wenn mans im Quelltext sieht und verstehen soll.
Und weils dazu wohl bis dato nicht einen gescheiten Editor auf dieser Erde gibt (Suchen, ersetzen, kopieren, verschieben, alles ganz einfache Dinge ), da bevorzuge ich ein Textfile, das man einfach versteht und mit notepad++ be/ver-arbeiten kann - also dann am ehesten JSON.
Ich denke an so sachen wie ne Visu-Seite duplizieren, kurz mal 50 oder 500 Objekte verschieben/kopieren etc. -> genau das kekst mich am HS z.B. ziemlich an (Stichwort: Klickorgie), das ich das nicht ohne weiteres mit einem einfachen Texteditor kann..

Makki

P.S.: Ich persönlich komm mit XML mittlerweile halbwegs klar, nur das hat echt ein bisschen gedauert..

[Chris M.]

Ich denke an so sachen wie ne Visu-Seite duplizieren, kurz mal 50 oder 500 Objekte verschieben/kopieren etc. -> genau das kekst mich am HS z.B. ziemlich an (Stichwort: Klickorgie), das ich das nicht ohne weiteres mit einem einfachen Texteditor kann..

Mal kurz die hier für mich wichtigen Punkte:

Pro XML:

• Syntax und Inhalt ist sauber getrennt - d.h. als Daten-Nutzer muss ich mir keinerlei Gedanken über falsch / kaputt formatierte Config-Daten machen.
• Der (Power-)Anwender kann per XSD seine Syntax überprüfen.
• Ein guter XML-Editor (ich kenne auch keinen, da ich noch nicht gesucht habe) könnte auf Basis der XSD eine ganz komfortable Editiermöglichkeit bieten.
• Man kann ganz leicht Tools bauen, die die XML modifizieren - z.B. für einen Massenimport, da so Themen wie XPath etabliert sind.
  (Mit XSLT gibt's sogar eine eigene Programmiersprache dafür - aber leider dürfte die für viele als Frakshow durchgehen, da die wirklich intelligenten Konzepte dahinter ganz anders als klassische Programmiersprachen sind. Genau so geht das geniale Paradigma der funktionalen Programmierung oft als Freakshow durch - auch ich hatte bei den Informatik-Vorlesungs-Hausaufgaben geflucht - aber das ist ein anderes Thema...
  Freunde klassischer Programmierung dürfen die mächtigen XML-Erweiterungen nutzen, die jede vernünftige Programmiersprache inzwischen bietet. PERL, Python, PHP, ...)
• Wir nutzen den simplen Subset von XML der genau so wie HTML aussieht - was inzwischen auch Hinz und Kunz können (so Scherze wie Namespaces sind da ja draußen, auch wenn ich bei der Status-Bar schon mal versucht war HTML als Subset einzubinden...)

Contra XML:

• XML ist nicht als von Menschen zu editierendes Format gedacht, sondern als Austauschformat für strukturierte Informationen - die von Menschen lesbar sein sollen (also eigentlich genau das, was wir hier brauchen...)
• Es gibt keinen (mir bekannten) guten, freien XML Editor

Pro JSON:

• Simpel, schnell und von JavaScript gut unterstützt
• Leicht editierbar (s.u.)

Contra JSON:

• Schwer editierbar (s.o.) - da keine starres Format existiert, an dem man sich entlang hangeln kann.
  (Das ist wie mit Formularen: wenn's eins gibt, schimpft jeder, dass man da seine Infos irgendwie reinpressen muss - aber wenn's keines gibt und man als Freitext das ganze machen soll ist's noch schlimmer, da man nicht weiß, was man wie schreiben soll und Angst hat die Hälfte zu vergessen...)
• Für die Anwendung ist's eine ganz gefährliche Sache - denn der Anwender kann beliebigen Müll reinschreiben das vom Format überhaupt nicht zu den erwarteten Daten passt (auch wenn's valides JSON ist).
  Hier muss man dringend ein sauberes Parsen des JSON-Objektes (also der Datenstrukturen im RAM) durchführen mit entsprechenden Fehlermeldungen. (Ein ekeliger Job...)

In Summe finde ich die Entscheidung eine Config-Datei als XML zu machen immernoch richtig. Einen Flame-War würde ich diesbezüglich jedoch nicht anzetteln, mit JSON könnte ich auch leben.

[Chris M.]

Gut das wir drüber geredet haben, ich schau mir das bei nächster Gelegenheit mal an ob sich das so umsetzen lässt

Hallo Julian, kannst Du mal bisschen Feedback über den Stand geben?

[netzkind]

kannst Du mal bisschen Feedback über den Stand geben?

Im Westen nichts neues.
Ich bin mit meinem Entwicklungsstand ein winzigkleines Stückchen weitergekommen, hab aber das Problem dass ich inzwischen mit dem ganzen restlichen Code des "Editors" nicht mehr wirklich einverstanden bin (it's a hack job) und jetzt bei der Überlegung das alles zu refactoren steckengeblieben bin

Eine Timeline kann ich dadurch jetzt nicht mehr vorweisen ...

Grüße,
Julian

[Chris M.]

hab aber das Problem dass ich inzwischen mit dem ganzen restlichen Code des "Editors" nicht mehr wirklich einverstanden bin (it's a hack job)

Ha, das kenne ich!

Könntest Du nicht den Hack-Job bei minimalem Aufwand noch so weit bringen, dass der Editor wieder läuft, wir ein Release machen und Du dann genug Muße hast den auf Wunsch-Stand zu bringen?

Wir hätten dann nämlich nicht nur ein Release, sondern auch einen funktionsfähigen Editor beim Weiterentwickeln des Restes

[netzkind]

Hab aktuell keine Schreibrechte aufs SVN - any ideas?

Julian

[Chris M.]

SourceForge hatte einen Hack, d.h. die haben zur Sicherheit alle Accounts deaktiviert und man muss sein Passwort per eMail resetten damit man wieder darf.

[netzkind]

Jo, war mir bekannt. Kennwort hab ich geändert, habe aber dennoch keinen Zugriff aufs SVN.
Laut Projekt-Seite bin ich daran auch garnicht mehr beteiligt ... oder ich finds nicht ...

Grüße,
Julian

[Chris M.]

Laut Admin-Seite (https://sourceforge.net/project/admi...roup_id=296426) bist Du Member - genau so wie immer... (Das einzige was sich geändert hat, ist das ich den User "Christian" als Admin hinzugefügt habe - im Rahmen der SF-Troubles bin ich nämlich wieder über meinen alten Account gestolpert...)

Was ich auch noch hatte, war das sich anscheinend der SSH-Key von SF geändert hatte. Dem kdesvn musste ich erlauben einen neuen Key (oder war es ein nicht öffentlich zertifiziertes SSL?) zu lernen.

Was passiert denn, wenn Du in ein anderes Verzeichnis einfach mal frisch auscheckst?