Im Moment wird bei jeder Plot-Generierung das GPLOTFILE entweder aus dem Dateisystem oder aus der Datenbank neu eingelesen. Das wäre eigentlich solange nicht notwendig, solange es in der Datei keinerlei Änderungen zur Laufzeit gibt.
Deshalb schlage ich vor, das gplotfile zu cachen und nur dann neu einzulesen wenn:
- das gplotfile über den Plot-Editor neu geschrieben wird
- das gplotfile über "Edit files" geändert wird
- der Anwender ein "set <SVGname> clearCache" ausführt, beispielsweise nach externem Editieren der Datei
Sowohl Dateisystem, als auch DB haben ein Cache. Auf meinem Testsystem dauert das Einlesen+Parsen <0.001sec, ich gehe davon aus, dass selbst auf langsamen Systemen <0.1s ist, und damit mAn zu wenig, um die erhoehte Komplexitaet zu rechtfertigen.
Es wird aber jedesmal eine Verbindung zur Datenbank hergestellt und wieder geschlossen. Und Datenbank-Handles wollen auch verwaltet sein, solange sie existieren.
Das vorgeschlagene Verfahren hat sich an anderer Stelle (02_RSS.pm) schon sehr lange bewährt. Dort wird die Layoutdatei in den Speicher gelesen und dann immer nur noch von dort verarbeitet.
Vielleicht sollte man das Cachen auch besser direkt in FileRead() implementieren und nur dann tatsächlich auf Filesystem oder Datenbank zugreifen, wenn seit dem letzten FileRead() bereits ein FileWrite() der gleichen Datei stattgefunden hat. Dann würde das Cachen systemweit funktionieren, ohne dass man sich im Modul darum kümmern muss.
BTW: Mit der Begründung "erhöhte Komplexität" irgendwelche vorgeschlagene Änderungen abzuschmettern finde ich ziemlich schräg, wenn ich mir so anschaue, was in den letzten Wochen alles umgesetzt wurde, was niemand haben wollte und was bis heute nicht richtig funktioniert.
Meine Begruendung ist erhoehte Komplexitaet (im Programm und beim Anwender) fuer kaum spuerbaren Gewinn. Die Aenderungen, die "niemand haben wollte" standen bei mir seit einem Jahr auf der TODO Liste, weil es gewuenscht wurde, weitere jQuery Widgets wie Knob verwenden zu koennen. Auch andere Probleme wie beim loadScript wurden mit deutlichen Worten bemaengelt.
Siehe auch http://forum.fhem.de/index.php?topic=32660.new#new
Naja, man sollte aber "übers Knie gebrochene" Dinge wie beispielsweise die Rotfärbung von "Save config" auch zurückziehen, wenn man erkennt, dass es nicht so funktioniert wie geplant. Und es funktioniert letztendlich nicht nur bei mir nicht.
Wir machen doch fhem für die Anwender und nicht für die Handvoll Entwickler, die daran arbeiten.
Was mich im Moment an der ganzen fhem-Entwicklung ein bisschen stört, ist der Eindruck, dass inzwischen offenbar nur noch Andre und Du darüber entscheiden, was "gut" sei - mir kommen da oft die tatsächlichen Belange der Anwender einfach zu kurz.
Mit dem Nicht-Cachen kann ich leben. Wenn Du das nicht generell einbauen willst, baue ich das zumindest für die configDB Anwender auf meiner Seite ein.
Frage am Rande:
Würde ein cachen auch ohne db gehen?
Das changed ging bin mir nur direkt nach dem speichern weg. Kann damit leben dass es aktiv ist und habe dafür auch schon das style erweitert (Grün anstatt rot) :)
Hi,
bin nicht sicher ob das gemeint war:
es gibt ein SVG-caching, siehe attr FHEMWEB SVGcache
l.g.erwin
Zitat von: Blackcat am 23 Januar 2015, 15:18:31
Frage am Rande:
Würde ein cachen auch ohne db gehen?
Es würde gehen, wenn Rudi es wollte - siehe oben. Mein vorgeschlagener patch würde unabhängig von configDB oder fhem.cfg funktionieren.
Zitat von: erwin am 23 Januar 2015, 15:35:46
bin nicht sicher ob das gemeint war:
Nein, hier geht es um was anderes.
ZitatUnd es funktioniert letztendlich nicht nur bei mir nicht.
Es funktioniert mAn sehr wohl allerdings setzen einige Module mit einem Timer irgendwelche Attribute. Daraus entsteht der Eindruck, dass die Anzeige kaputt ist. Ich faende es sinnvoll darueber nachzudenken, ob das noetig ist, oder ob CommandAttr das Flag nicht setzt, falls das Attribut sich nicht geaendert hat.
Zitat von: rudolfkoenig am 23 Januar 2015, 15:54:09
Es funktioniert mAn sehr wohl
Deine Meinung ist Dir natürlich ungenommen, auch wenn die Aussage inhaltlich dadurch nicht richtiger wird.
Zitat von: rudolfkoenig am 23 Januar 2015, 15:54:09
allerdings setzen einige Module mit einem Timer irgendwelche Attribute
Ich habe die falsche Rotfärbung bereits mit der originalen fhem.cfg die im Auslieferungspaket von fhem enthalten ist. Ganz ohne eigene definierte devices.
Hmm. Ich nicht.
tja, Du weisst, ich hasse JavaScript - wieder ein Grund mehr.
Und dass es bei Dir funktioniert, hilft mir auch nicht weiter.