CometVisu - (interner) Beta-Test

[netzkind]

Ich denke das expires macht mal auf jeden Fall Sinn, das sollte viele der Caching-Probleme schmerzfrei lösen.
Warum ich auf die Idee erst jetzt komme sei mal dahingestellt

Veto.

Ihr versucht grade ein Feature des Browsers abzuschalten das auf unserer Seite ist. Ich versteh das echt nicht - wieso das die Lösung sein soll.

Für jede Anfrage die der Browser an den Server sendet muss er erst auf die Antwort warten bevor er die Seite weiter rendert, bzw. weitere Anfragen an den Server stellt. Je nach Browser und Device ist die Zahl paralleler Anfragen gering, so dass wir durch jeden Request den wir zusätzlich an den Server schicken länger darauf warten müssen dass die Seite aufbaut. Je nach Latenz der Verbindung (Mobilfunk?) verschenken wir damit das was wir behaupten dass der Vorteil dieser Browser-Visu ist: dass sie rattenschnell ist.

Ich sage nicht dass "Expires" keinen Wert hat - ich würds aber auf +1 Monat (oder noch höher) stellen um den Browser-Cache richtig auszunutzen.

Grüße,
Julian

[netzkind]

Aber aus dem Bauch raus gefällt mir diese Lösung nicht, da hier am Symptom und nicht an der Lösung rumgedoktort wird.

Sorry, dem muss ich vehement widersprechen.

1) expires ist keine Lösung, weil wir damit nur so tun als wüssten wir wann sich die Datei das nächste mal ändert - was wir aber natürlich nicht tun. Wir setzen ihn nur so niedrig dass einfach immer nachgefragt wird.
2) jeder roundtrip kostet Zeit, nach ein paar Cookies passt der Anfrage-Header nicht mal mehr in ein Datenpaket und dann dauerts gleich richtig.
3) wenn wir in den Dateinamen Versionsnummern unterbringen dann erschlagen wir damit das Problem, weil wir dadurch genau wissen wann sich eine Datei geändert hat - nämlich mit einer neuen Version, und in der Zwischenzeit kann der Client das tun was er möglicherweise am besten kann: cachen.

Das ist kein rumdoktorn an Symptomen: das ändern von Expires ist rumdoktorn, weil wir nämlich garnichts wissen und einfach mehr Last auf der Leitung erzeugen um das auszugleichen.
Versionsnummern in den Dateipfaden/Namen ist ein Vorgehen wie es AFAIK von der ganzen Branche umgesetzt wird. In meinem Beispiel als GET-Parameter, damit wir keine rewrite-Regeln aufsetzen müssen.

Wo es zugegebenermaßen nicht funktionieren wird:
- Konfiguration; diese muss der Client regelmässig neu anfragen; da müsste ein cache-control: must-revalidate her, oder halt JS-seitig den Cache übergehen
- bei Entwicklern: wer CSS oder JS anfasst sollte genug von Webentwicklung verstehen dass er weiß wie man einen Cache leert und dass das notwendig ist; ich denke das ist ein wichtiger Punkt für die Dokumentation, das noch mal anzusprechen


Was auch nicht funktionieren wird, ist die SVN-Revision (svn:keywords) als Versionsnummer zu verwenden, da diese zum Commit-Zeitpunkt einer Datei nur in die Dateien dieses Commits eingetragen wird - man müsste also jedesmal die "Konfigurationsdatei" mitcommitten. Deshalb schlage ich vor bei jedem Release eine Versionsnummer in eine der Dateien einzupflegen.

Meine Meinung zu dem Thema ist klar: das Caching des Browsers aushebeln ist ein no-go.

Grüße,
Julian

[makki]

Und denen darf man zumuten (v.a. wenn's gut dokumentiert bzw. angekündigt wurde) hier per Hand das selber zu mergen.

Schon, aber die Frage und den Thread hab ich dann trotzdem an der Backe

Grundsätzlich übrigens, wo wir grad beim Thema sind:
Am besten ist es, eigene Anpassungen in sep. configs unter /etc/lighttpd/conf-available/... anzulegen und mittels
lighty-enable-mod
zu aktivieren..

Dann knatscht auch nichts, ich fasse soweit möglich die Debian/package-configs nicht an (in diesem Fall, lighttpd.conf, geht das wegen der Reihenfolge von mod_expire|compress aber nicht anders)
Immerhin ist squeeze jetzt stable (Debian 6.0) und da werden wir uns schon was ausdenken, das die vorhandenen WG nicht ewig eine alte Distribution drauf haben (nur genau da wird jede Modifikation dann sehr spannnend..)

Eine Gratwanderung bleibts, ein full-fledged, offenes Linux auch einfach klickbar und trotzdem anpassbar zu halten&machen

Makki

[Chris M.]

(problematisch daran ist, die die ihre lighttpd-config angepasst haben.. Wird halt ein schmutziger sed-patch..)

Vermutlich kann man es sich hier etwas einfacher machen:
Nur "Power-User" ändern die lighttpd-config selber. Und denen darf man zumuten (v.a. wenn's gut dokumentiert bzw. angekündigt wurde) hier per Hand das selber zu mergen.

Aber ein komfortabler für den Kunden ist natürlich der Sed-Hack

[makki]

Ich denke das expires macht mal auf jeden Fall Sinn, das sollte viele der Caching-Probleme schmerzfrei lösen.
Warum ich auf die Idee erst jetzt komme sei mal dahingestellt
(problematisch daran ist, die die ihre lighttpd-config angepasst haben.. Wird halt ein schmutziger sed-patch..)

Makki

[Chris M.]

Alternative:
wir nutzen die aktuelle SVN-Revision oder die Release-Nummer als Cache-ID. Jede aus dem JS angeforderte Datei bekommt einen irrelevanten Parameter angehängt der diese Revisionsnummer enthält. So ist bei jedem neuen Release beim Client hinsichtlich CSS und JS (solange er es nicht selbst anfasst, also kein Entwickler ist) automatisch alles takko - wir müssten nur beim schnüren des Releases an zentraler Stelle die Release-Nummer so hinterlegen dass das JS drauf zugreifen kann.

Dazu könnte man das Keyword-Replacement von SVN (mit-)nutzen (property svn:keywords).

Aber aus dem Bauch raus gefällt mir diese Lösung nicht, da hier am Symptom und nicht an der Lösung rumgedoktort wird.

[netzkind]

Ähm, IMHO ist das keine Lösung Im Alpha/beta kein Problem aber "in echt" muss das einfach lüppen..

Dito: Selbst der Button/Link wäre IMHO nur ein Alpha/Beta-Workaround, keine Lösung: von einer Visu darf man erwarten, das sie sofort die aktuelle XML-config, CSS & Co verwendet

Alternative:
wir nutzen die aktuelle SVN-Revision oder die Release-Nummer als Cache-ID. Jede aus dem JS angeforderte Datei bekommt einen irrelevanten Parameter angehängt der diese Revisionsnummer enthält. So ist bei jedem neuen Release beim Client hinsichtlich CSS und JS (solange er es nicht selbst anfasst, also kein Entwickler ist) automatisch alles takko - wir müssten nur beim schnüren des Releases an zentraler Stelle die Release-Nummer so hinterlegen dass das JS drauf zugreifen kann.
Zusätzlich würde ich die Config ggf. einfach immer no-cache lesen, oder halt den Reload-Link tunen; wenn das XML noch deflate transportiert wird ist alles in Butter.

Und als Entwickler sollte man - während der JS/CSS-Entwicklung - im Browser das Caching sowieso komplett deaktivieren (bsp. Firefox: "Web Developer"-Addon - Toolbar "Deaktivieren" - "Cache deaktivieren"). Dann entsteht das Problem da garnicht erst, und man hat nicht das Problem dass man nicht nachvollziehen kann ob man nun grade den neuen oder doch alten Code am Laufen hat.

Meine 2 Cent dazu

Grüße,
Julian

[makki]

$.ajaxSetup({cache: !forceReload});

Ich schätze das ! (=not) muss ich 10x übersehen haben

Unser Weg raus ist also dem User zu sagen "lösch deinen Cache"

Ähm, IMHO ist das keine Lösung Im Alpha/beta kein Problem aber "in echt" muss das einfach lüppen..

oder einen Reload-Button anbieten der den Cache durch anhängen

Dito: Selbst der Button/Link wäre IMHO nur ein Alpha/Beta-Workaround, keine Lösung: von einer Visu darf man erwarten, das sie sofort die aktuelle XML-config, CSS & Co verwendet

(deshalb teste ich da auch noch ein bisschen rum aber es sieht mit expire bisher gut aus: der 304 kostet ja quasi "nichts")

Makki

[Chris M.]

Naja, nicht nur beim entwickeln, wenn die config geändert wird und der Browser die alte bis zum St.nimmerleinstag cached ist auch nicht toll

Ok, einfach an die URL "forceReload=true" anhängen, dann lüppts. Ich dachte das wäre in der Demo-Visu im Footer-Link "Reload" mal enthalten gewesen, scheint aber nicht der Fall zu sein.

Wie Julian schon geschrieben hat, einfach auf

http://wiregate/visu/?forceReload=true

gehen, dann wird die Config sicher frisch geladen. IIRC war das aber nie Bestandteil beim "Reload"-Link unten auf der Seite... (würde aber Sinn machen)
Wichtig zu wissen ist aber, dass das wirklich nur für die Config gilt - nicht für die CSS, JS, ... was mich beim Entwickeln behindert (aber nicht verhindert ).

[Multi-Einträge]Klare Antwort:[Editor-Hack]

Das war meine Vermutung - aber ich wollte nachfragen, nicht dass das sogar gehen würde und ich trotzdem außenrum programmiert hätte...

Das ist definitiv so erwartet, und wird sich meiner Einschätzung nach niemals ändern, weil der Editor sonst magisch erraten müsste was der Entwickler eines Plugins sich vorstellt dass ein "button"-Tag noch so für Attribute hat, welche Datenbasis für welche Attribute verwendet werden müssen - und vor allem: wie diese Attribute strukturiert dargestellt werden sollen. Falls es dazu Ideen gibt wie man das dynamisieren kann lass ich mich gerne überzeugen

Ideen gibt's sicher, wenn man sich mal die Anforderungen genauer strukturiert. Muss mal drüber nachdenken...

Gleichzeitig bin ich aber davon überzeugt dass wir immer den Editor an die Widgets anpassen müssen: neue Widgets werden neue Anforderungen mitbringen wie und welche "Einstellungen" sie benötigen. Und man kann sich schwer ausmalen was Widgets noch alles abgefahrenes brauchen werden

Klar, keine Frage. Nur wenn man die Anforderung, die beim Widget-Entwickeln entsteht, klar spezifizieren kann, dann ist es angenehmer, wenn die "logische Reihenfolge" eingehalten werden kann. D.h. wenn der Editor vorlegt und das Widget dann das bestehende nutzen kann. (Und spätestens zum jeweiligen Release sollte dann beides zusammenpassen)
Die Zahl dieser Änderungen dürfte aber mit der Zeit eh runter gehen, da das Set an Funktionen ja immer vollständiger wird.

[netzkind]

@caching:
das überrascht mich jetzt alles nicht so.

Also: Strg-Reload bringt nichts, weil das XML nicht Teil der Seite ist, sondern per Skript nachgezogen wird - da gilt das "force reload" nicht mehr für den Browser.
Gleichzeitig gab es im Code der templateengine.js bereits eine Zeile die dafür sorgte dass das XML niemals aus dem Cache geladen wird.

Die wurde aber geändert nach:
$.ajaxSetup({cache: !forceReload});

Ok, einfach an die URL "forceReload=true" anhängen, dann lüppts. Ich dachte das wäre in der Demo-Visu im Footer-Link "Reload" mal enthalten gewesen, scheint aber nicht der Fall zu sein.

Siehe hierzu auch:
Two Important Differences between Firefox and IE Caching – HttpWatch Blog

Absatz 2 zu "If You Don’t Specify an Expiration Date Firefox May Set One for You". Er verhält sich also gemäß RFC2616. Details im verlinkten Artikel. Ich nehme mal an dass bspw. Webkit (Chrome, Safari) sich auch nach dieser RFC richten.

Schön sieht man es in Firefox Firebug (siehe angehängtes Bild).

Unser Weg raus ist also dem User zu sagen "lösch deinen Cache" oder einen Reload-Button anbieten der den Cache durch anhängen eines irrelevanten Timestamps an die URLs übergeht (womit wir wieder bei forceReload=true sind).

Grüße,
Julian

[netzkind]

Kannst Du das noch in den Editor einbauen?

Ich glaube so rum ist das leichter, als wenn die Widgets vorlegen und dann der Editor nachziehen müsste...

rev #291.

Gleichzeitig bin ich aber davon überzeugt dass wir immer den Editor an die Widgets anpassen müssen: neue Widgets werden neue Anforderungen mitbringen wie und welche "Einstellungen" sie benötigen. Und man kann sich schwer ausmalen was Widgets noch alles abgefahrenes brauchen werden

Grüße,
Julian

PS:
hatte vergessen das "type"-Attribut für Adressen zu committen (was übrigens jetzt einfach so wieder geht) - das ist in rev #290.

[netzkind]

Hi Chris,

Nun was anderes @Julian:
Im Code sehe ich nun etwas wie

address:    { type: 'address',   required: true, multi: true }

Das wollte ich gleich mal missbrauchen beim Basteln eines Multiswitches / Multitriggers (der für Szenen aber auch für den Heizungbetriebsmodus verwendet werden soll) und hatte für die Beschriftung von n Buttons eine Zeile wie

button:     { type: 'string',    required: true, multi: true },

einfügen.
Leider funktioniert die nicht so wie erwartet (nämlich dass nun ein "String-Multiedit" erscheint).
--> Ist das zu erwarten, oder mache ich da was falsch?

Klare Antwort:

Zumindest beim Editor machen wir auch grade definitiv technische Schulden die uns beim nächsten Ändern der Datenstruktur richtig Probleme bereiten dürften. Das Maß in dem beim Editor die Strukturen hartcodiert sind, oder auch die Komplexität der Konstrukte macht den Code schwer wartbar.

Das ist definitiv so erwartet, und wird sich meiner Einschätzung nach niemals ändern, weil der Editor sonst magisch erraten müsste was der Entwickler eines Plugins sich vorstellt dass ein "button"-Tag noch so für Attribute hat, welche Datenbasis für welche Attribute verwendet werden müssen - und vor allem: wie diese Attribute strukturiert dargestellt werden sollen. Falls es dazu Ideen gibt wie man das dynamisieren kann lass ich mich gerne überzeugen

Das mit dem "multi" zielt schon in die richtige Richtung, aber jedes Element das irgendwie als multi dargestellt werden soll muss hartcodiert im Editor bekannt sein. Im Moment rennt das in der visuconfig_edit.js bei Zeile 442ff hier rein:

                            } else {
                                // handling for "if an element can appear more than once"
                                // TODO: needs to be coded once someone wants to use it :)
                            }

Grüße,
Julian

[makki]

Gerade beim Entwicklen ärgert er mich hier wieder

Naja, nicht nur beim entwickeln, wenn die config geändert wird und der Browser die alte bis zum St.nimmerleinstag cached ist auch nicht toll

Aber das mod_expire scheint da zu wirken..

Quickfix: (wie ich das zuverlässig per Paket einfummle muss ich mir noch ausdenken)

root@wiregate231:~# cat /etc/lighttpd/lighttpd.conf
# Debian lighttpd configuration file
#

############ Options you really have to take care of ####################

## modules to load
# mod_access, mod_accesslog and mod_alias are loaded by default
# all other module should only be loaded if neccesary
# - saves some time
# - saves memory

server.modules              = (
            "mod_access",
            "mod_alias",
            "mod_accesslog",
[B]# load expire BEFORE mod_compress!
            "mod_expire",
[/B]            "mod_compress",
..

[B]$HTTP["url"] =~ "\.xml" {
    expire.url = ( "" => "access plus 10 seconds" )
}
[/B]

Oder hardcore: Global (ohne $HTTP..), zum entwickeln vielleicht praktisch, fürn echtbetrieb nicht so das wahre:

expire.url = ( "/" => "access plus 5 seconds" )

und (Edit: einmalig)

root@wiregate231:~# rm /var/cache/lighttpd/compress/visu-svn/*.xml

Makki

[Chris M.]

Eben war es wieder soweit,

Gerade beim Entwicklen ärgert er mich hier wieder

mod_compress (wir sind ja totale sparfüchse und zippen selbst dynamische Daten - bringts über UMTS&co aber z.B auch messbar!)

Das ist eigentlich eine einfache Rechnung, wenn das Zippen und Entzippen schneller ist als die dadurch gesparten Bytes durch die Luft zu jagen dann lohnt sich das.
Oder anders gesagt, wenn wir ganz optimal sein wollten, müssten wir je nach Endgerät und Übertragungsstrecke das dynamisch einstellen...
Pragmatisch: einfach immer komprimieren

Nun was anderes @Julian:
Im Code sehe ich nun etwas wie

address:    { type: 'address',   required: true, multi: true }

Das wollte ich gleich mal missbrauchen beim Basteln eines Multiswitches / Multitriggers (der für Szenen aber auch für den Heizungbetriebsmodus verwendet werden soll) und hatte für die Beschriftung von n Buttons eine Zeile wie

button:     { type: 'string',    required: true, multi: true },

einfügen.
Leider funktioniert die nicht so wie erwartet (nämlich dass nun ein "String-Multiedit" erscheint).
--> Ist das zu erwarten, oder mache ich da was falsch?

[makki]

wenn bereits eine Version vorhanden ist, also auch eine visu_config.xml,
dann wartet er auf eine Eingabe wie verfahren werden soll.

Ist auch so beabsichtigt, ein bisschen dämlich aber so wird wenigstens nichts ungefragt überschrieben und der Anwender gezwungen, sich mit der Frage zu beschäftigen
Mit dem nächsten Patchlevel wird das allerdings (für alle Packerl beim Update via Webif) geändert: dann werden geänderte configs grundsätzlich nicht überschrieben aber auch keine dummen Fragen mehr gestellt - und ggfs. die aus dem Paket als .dpkg-dist abgelegt.
Für das Debian-Paketverwaltungssystem braucht man wohl ein paar Jahre, ist so

Makki