Hi,
jmaus hat geschrieben:
Zusätzlich könnte ich natürlich auch gleich noch ReGaHss anpassen und die gleichen Cache-Control header dort drin umsetzen, oder denkst du das das keinen Sinn macht? Momentan gibt ReGaHss ja immer "Cache-Control: no-store, no-cache" aus.
Kann ich nicht ohne weiteres beurteilen. "no-store, no-cache" sorgt ja prinzipiell dafür, dass es gar nicht gecached werden soll. Mit den Header vom PR würde das dann auf einmal gecached werden. Wenn das Verweise auf statische Dateien sind, wäre das vermutlich fein, bei Verweis auf dynamisches eher ungut.
Bevor du was änderst sollte man imho erstmal über das unten diskutieren.
jmaus hat geschrieben:
deimos hat geschrieben:
Ich war auch etwas erstaunt zu sehen, dass das mit dem Versionsparameter teilweise schon vorhanden ist. Allerdings in mind. 3 verschiedenen Varianten (CCU Firmware Version, JSQuery-Version (auch bei CCU JS Dateien), große Zahl (Unix Timestamp, Hash? Keine Ahnung)). Irgendjemand bei eQ-3 muss sich die Gedanken also schon mal gemacht haben, aber dann leider nicht konsequent beendet haben.
Bevor man das Thema mit den Versionsnummer angeht, sollte man daher in meinen Augen mal diskutieren, auf welche Methode man das vereinheitlicht.
Das mit den unterschiedlichen Versionsparametern habe ich auch bereits gesehen und war auch selbst überrascht darüber
Was die einheitliche Methode angeht so würde ich kurzerhand dafür plädieren einfach die CCU Firmwareversion dort jeweils einzusetzen. Die Frage wäre nur wie man an die Version an der jeweiligen stelle dann immer rankommt um diese dann als parameter ausliefern zu lassen.
Innerhalb der RegaHSS ist das vermutlich trivial, da einfach immer die Version auszugeben. (ggf. einmal statisch aus der /boot/version lesen, wenn die nicht sowieso schon bekannt ist)
Tricky wird es jetzt bei den statischen Dateien: Wäre da irgendein Build-System hintendran, wäre es auch wieder trivial, aber das ist ja scheinbar nicht der Fall.
Initial einfachster Weg: Statisch in die Datei schreiben. Ist dann aber gleich eine Wartungshölle.
Anderer Weg wären Server Side Includes (SSI). Auf einem Raspberry würde ich da keine Probleme sehen. Aber bei der Original CCU, eher schlecht...
Letzter Weg: Nicht statisch mit Script-Tag (bzw. Link-Tag bei CSS) einbinden, sondern mittels dynamischen Javascript Include (grob in diese Richtung:
http://www.javascriptkit.com/javatutors ... tcss.shtml
Wirklich prickelnd sind alle Lösungen nicht, nicht ohne Grund sind ja auch die ganzen Build-Systeme für Webanwendungen entstanden.
Ich bin an der Stelle jetzt leider wieder beim eQ-3 Bashing: Egal welche Lösung es sein soll, sie sollte zügig sowohl in OCCU als auch in der Dev-Version der Original CCU sein. Der Umweg das erst in RaspberryMatic zu testen, dann in OCCU einzupflegen und vielleicht dann irgendwann auch in der Original CCU ist imho nicht zielführend und erzeugt Mehraufwand und potentielle Fehlerquellen, weil der ursprüngliche Patch dann immer wieder an die Weiterentwicklung angepasst werden muss. Daher bin ich klar der Meinung, dass das seinen Weg von internen Dev Sourcen bei eQ-3 über OCCU nach RaspberryMatic nehmen muss und nicht andersrum.
Viele Grüße
Alex
