CometVisu - (interner) Beta-Test

[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

[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

[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.

[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.]

(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]

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

[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

[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

[makki]

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.

Einverstanden, wir alle wollen - ggfs. auf Teufel komm raus - 110% Performance; mindestens irgendwas muss ja auch richtig besser sein und mein Ziel ist immernoch, das es mindestens doppelt so schnell wie CommanderconFusion ist (was übrigens derzeit locker so ist)
Aber deswegen sprechen wir ja auch darüber und deswegen fragte ich, bevor das Fakt wird..

Kompromissvorschlag:
- Expires für die *.xml (optimal wäre, der Client prüft das auch alle XX Minuten - denkt man an 5 Visus im Haus). Kostet dann einen 304 beim laden oder alle XX Minuten; problematisch ist das ja nur bei dyn. php/pl/whatever, statische Files beantwortet der lighty in 30ms mit 304
Weil wann sich die config ändert, naja, das weiss man eben nicht..
- ?rev=SVNREV/Versionnummer für alles andere (js, css, ..)
Wer entwickelt und daran dreht, dem ist IMHO wirklich zuzumuten, sich das no/clear-cache Plugin im Browser zu installieren.. (sollten wir aber dokumentieren, weil die Lernkurve hier auch recht steil ist und das ist einer der pitfalls..)

Makki

[Chris M.]

- das "zappeln" der Slider besser in den Griff bekommen

Beim Slider gab's einen bug der die Updates beim Sliden verhindert hatte und es gab einen Bug im Encoding des DPT:5.010 der für fieses Zappeln sorgen konnte.
=> Beides ist jetzt behoben, bitte mal schaun, ob der Punkt so nun noch offen ist.

Zur Zeit versuche ich endlich meine Touchs in den Serien-Betrieb zu überführen (inkl. automatischer An- und Abschaltung) so wie die Basis-Visu hier laufen zu lassen (der WAF hat schon die Höhe des damaligen Invests in Frage gestellt )
=> Durch das "Eat your own food" ist man durchaus gezwungen Fehler zu beheben, über die man sonst leicht hinweg gesehen hatte...

@Julian: Im Chromium mag der Editor nicht so ganz, bzw. die Buttons und Select-Boxen funktionieren (meistens) nicht. Kannst Du da mal schaun?

@Expire vs. Namen: Noch bin ich hier am Nachdenken was die beste Lösung ist. Denn ihr könnt Euch sicher sein, ich will keine gute Lösung, ich will die technisch beste und sauberste...
Das der Entwickler mit Einschränkungen leben können muss, die ein Anwender nicht sehen darf (z.B. den Cache ausschalten) bin ich d'accord.
Ein Cachen ohne nachzufragen, ob sich was geändert hat, finde ich dagegen technisch höchst unbefriedigend da gefährlich - auch wenn dadurch Traffic erzeugt wird (der wird aber nur zur Setup-Time und nicht zur Run-Time erzeugt!), der natürlich meistens per 304 beantwortet werden sollte.
Cookies sollten uns dagegen nicht stören - denn ich wüsste nichts, was bei der CometVisu ein Cookie erfordert (wer setzt eigentlich momentan das "sid" und das "testing" Cookie - das sollten wir rausnehmen!)

[makki]

Beim Slider gab's einen bug..

VIIIEL besser !

Wo die Kekse herkommen: keine Ahnung, ich wäre mir keiner Schuld bewusst, scheint auch nur im FF und wenn man sie löscht, werden sie auf die schnelle scheinbar auch nicht wieder erstellt..
Evtl. ein FF/Firebug-interna (?)

Makki

[makki]

Mal so eine Frage, ich hab ja bei JS ned so wirklich den durchstieg, was die in handelsüblichen Browsern real verfügbaren Optionen angeht:

Angenommen, man spart sich den Webserver für read/write (die Files, html,xml,js,css usw kommen natürlich nach wie vor von dort!) und geht direkt auf KNXnet/IP Tunneling (langsam, einige drawbacks) oder die eibd-API per TCP (groupcachelastupdates - genauso schnell/resourcenfreundlich wie aktuell)

Aber kann man denn einen nackerten Socket ohne HTTP mit jquery/Ajax machen? (also ohne HTML5 und Browser, die 2015 dann rauskommen natürlich..)
Weil falls ja, hab ich heute mit einem 30.- EUR CometVisu-Server gespielt

Makki

[netzkind]

Aber kann man denn einen nackerten Socket ohne HTTP mit jquery/Ajax machen? (also ohne HTML5 und Browser, die 2015 dann rauskommen natürlich..)

Weil ich mir da jetzt auch nicht sicher war hab ich meine Meinung mit der hier in der Abteilung abgelichen, und der aktuelle Zustand ist: nein, gibt es nicht.
Selbst Websockets sind nicht: WebSockets in Firefox 4 wegen Lücke im Protokolldesign deaktiviert [Update] | heise Security

Und normale Sockets gibt es in Javascript nicht ohne über Gateways zu gehen (bspw. über ein eingebettetes Flash wie “Real” Javascript Sockets! - Mayflower Blog oder https://code.google.com/p/jsocket/ )

Grüße,
Julian

[Chris M.]

Wie bereits geschrieben brauchst Du wenn, dann die Web-Sockets.

Aber das halte ich vom Design her für eine schlechte Lösung:

• KNX Tunneling => ein normales IP Gateway reicht nicht für mehrere Visus
• Das JavaScript muss das KNX Protokoll genau so gut wie der eibd können
• Bei einem Start des Systems fehlen die letzten Zustände - so überhaupt lesbar, würde erst mal eine riesige Paket-Flut entstehen
• Nur Browser die das implementieren können verwendet werden

Und ganz wichtig:

• das ist eine KNX proprietäre Lösung! (Keine Anbindung an die internen Werte der Logik Engine, kein xPL, kein ...)

Andererseits:
Das CometVisu-Protokoll ist so einfach, da kann man sich im Zweifel ganz leicht und schnell einen spezialisierten Deamon schreiben, der das benötigte HTTP-Subset spricht und versteht und der nur die eibd-Anbindung macht. Durch die Code-Minimalität ohne jegliche Bedenken bzgl. Sicherheit.
Und so klein, dass der selbst auf einem µC laufen würde...

[makki]

Na gut, hätte ja sein können (Das ich da nur was übersehen habe)
KNX,Rest: schon klar..

Läuft auch seit eben mit bekannter Umgebung, eibd&cgi PHP ist noch a bisserl a Problem mit 4MB Flash (von Perl reden wir mal nicht..)
Intern läuft das Gerät zwar nur als potentieller "1-Wire IP-Busmaster", aber es schadet ja nicht wenn die CometVisu auch schonmal drauf laufen würde

Makki