Demo der 0.8.x?

[Chris M.]

Es ist schon lustig, was bemerkt wird und was nicht.
Der dynamische Zoom beim Diagram ist wirklich schön - aber dass der Seitenwechsel bei der SV immer eine Lade-Gedenksekunde dauert hab ich noch nirgends beschrieben gesehen...

[henfri]

Hallo Chris,

doch, ich glaube, das habe ich weiter oben geschrieben -und gesagt hab ich es auch und ich glaube, es ist auch auf dem Video zu sehen -bin jetzt zu faul nachzusehen.

Wobei es auch wirklich nur auf dem Smartphone bemerkbar ist. Auf dem PC nicht. Hattest du bei deinem Versuch den Page-Cache an?

Es ist schon lustig, was bemerkt wird und was nicht.

Jepp! :-) Das gilt aber nicht nur für mich, meinst du nicht *zwinker*

Bitte fair bleiben. Ich habe versucht alle Vor- und Nachteile beider Varianten neutral darzustellen. Ich hoffe, das ist mir gelungen. Wenn ich hier etwas kritisiert habe, war das sicher beabsichtigt, aber ganz sicher auch konstruktiv.
Ich habe auch bemerkt, dass ihr an dem Thema dran seid.

Gruß,
Hendrik

[Chris M.]

Wobei es auch wirklich nur auf dem Smartphone bemerkbar ist. Auf dem PC nicht. Hattest du bei deinem Versuch den Page-Cache an?

Mein PC ist da eine üble Umgebung - den hab ich mit entsprechenden Erweiterungen (Firebug + ein paar weitere Plugins) da schon auf einen ziemlich unüblichen Stand gebracht - und dann sind da auch noch im Schnitt 100 Tabs auf 4 virtuellen Bildschirmen offen.
U.a. deswegen teste und entwickle ich inzwischen fast nur noch im Chrome - auch wenn ich im Firefox surfe...
=> Keine Ahnung was da der reale Stand war.

Es ist schon lustig, was bemerkt wird und was nicht.

Jepp! :-) Das gilt aber nicht nur für mich, meinst du nicht *zwinker*

[...]

Nö, das ist eine allgemeine Feststellung. Und die betrifft mich selbst auch - gerade wenn ich nur mal schnell einen Überblick will.
=> Ich hab das als Kritik aufgefasst - aber im positiven Sinn ("Theaterkritiker"), nicht als Motzen

[henfri]

Hallo,

na dann ist ja alles gut.
Page-Cache ist aber eine Einstellung in der Konfiguration der SV -Nix im Browser. Nach meinem Verständnis werden die html-Seiten dadurch vor-erzeugt, so dass diese nicht bei jedem Aufruf via php erzeugt werden müssen.

Bei der CV muss nach meinem Verständnis beim Seiten-Wechsel kein Code vom Server geladen werden (sondern nur die KNX-Daten), richtig?

Das ist sicher ein Vorteil der CV, der aber andererseits durch höhere Anforderungen an den Client (Speicher, Prozessor) erkauft wird, richtig?

Gruß,
Hendrik

[Chris M.]

Bei der CV muss nach meinem Verständnis beim Seiten-Wechsel kein Code vom Server geladen werden (sondern nur die KNX-Daten), richtig?

Richtig. Sobald die Visu im Browser geladen wurde, liegt alles notwendige vor und kann "flutschen". Nur noch die Daten werden aktualisiert - genau dann, wenn es neue gibt (d.h. unabhängig vom Seitenwechsel).

Das ist sicher ein Vorteil der CV, der aber andererseits durch höhere Anforderungen an den Client (Speicher, Prozessor) erkauft wird, richtig?

Richtig bzgl. RAM - aber hier wurde bewusst die Entwicklung der Hardware mit eingerechnet. Die CPU ist davon nicht betroffen.
Und: wenn man die Visu als "App" oder klassischen Client hätte, würde genau so viel RAM dafür verbraucht werden.
D.h. es entstehen dadurch keine Performance-Nachteile sondern eben Vorteile

[henfri]

Richtig. Sobald die Visu im Browser geladen wurde, liegt alles notwendige vor und kann "flutschen". Nur noch die Daten werden aktualisiert - genau dann, wenn es neue gibt (d.h. unabhängig vom Seitenwechsel).

Das wäre aber doch auch der Fall, wenn man die Visu-Seiten auf dem Handy Cached, oder? (cache.manifest)
Warum habt ihr das nicht so gemacht?

Richtig bzgl. RAM - aber hier wurde bewusst die Entwicklung der Hardware mit eingerechnet. Die CPU ist davon nicht betroffen.

Bei der CV muss doch 'live' aus xml html gemacht werden (denn das rendert der Browser, oder?). Das entfällt bei der SV (bzw. mach der Server). Ich weiß aber nicht, wie viel "Arbeit" das ist.

Und: wenn man die Visu als "App" oder klassischen Client hätte, würde genau so viel RAM dafür verbraucht werden.

Kommt das nicht darauf an, wie die "App" funktioniert? Sie könnte die Seiten (html?) ja auch jederzeit vom (schnellen) Flash laden, statt beim start komplett in den Flash.

Gruß,
Hendrik

[Chris M.]

Das wäre aber doch auch der Fall, wenn man die Visu-Seiten auf dem Handy Cached, oder? (cache.manifest)
Warum habt ihr das nicht so gemacht?

Den appcache nutzen wir schon seit einiger Zeit um Transfer-Volumen zu sparen

Bei der CV muss doch 'live' aus xml html gemacht werden (denn das rendert der Browser, oder?). Das entfällt bei der SV (bzw. mach der Server). Ich weiß aber nicht, wie viel "Arbeit" das ist.

Das betrifft auch etwas die Frage dadrüber.
Bei dem Systemdesign muss man sich überlegen, wo welche Ressourcen zur Verfügung stehen.

Bei einer klassischen Web-Seite habe ich einen (ausreichend) leistungsfähigen Server mit genug RAM, CPU, Storage, ... für die typische Zahl der zu erwartenden Kunden (und wenn dann mal Slashdot auf die Seite verlinkt geht's halt per Slashdot-Effekt vorübergehend in die Knie). Der Client dagegen ist vergleichsweise leichtgewichtig, weil der Browser nur nebenbei läuft (d.h. ein Programm von vielen ist), auf einem Mobil-Gerät läuft, ...
=> Hier kann man Ressourcen auf dem Server ausgeben um welche auf dem Client zu sparen.
Und bei modernen Seiten wird das eigentlich auch schon nicht mehr gemacht, da der Client einfach stark genug ist. Da gibt's höchstens noch dynamisches Bandbreiten-Management für Videos per Streaming.
Und die dynamischen Webseiten um die Erstellung der Webseiten zu vereinfachen (z.B. bei CMS) - d.h. hier gebe ich mehr für technische Ressource aus um humane zu sparen.

Und nun zu einer ganz anderen Welt: Heimautomatisierung.
Hier habe ich einen Server, der 24/7 laufen muss, d.h. der Stromverbrauch relevant ist. Der aber kaum Leistung haben muss, schließlich gibt es nur ganz wenige Clients, die auf den Server zugreifen.
Wir reden folglich von Servern wie einer Routern (gute 100 MHz, dickere um 32 MB RAM), WireGate / Alix.1d (500 MHz, 256 MB RAM) oder Raspberry Pi (700 MHz, 256 MB oder 512 MB RAM).
Und dazu von Clients die als PC / Laptop schon seit langem mit 3 GB aufwärts ausgestattet sind und eine CPU mit mehreren Kernen im GHz-Bereich. Oder von mobilen Geräten die auch RAM im Gigabyte Bereich und CPUs im Gigaherz-Bereich haben.
=> Hier hat der Client deutlich mehr Ressourcen als der Server!
=> Da der Server sehr lange im Einsatz bleibt (wer tauscht den schon gerne, wenn der läuft und das Haus davon abhängt?!?), die Clients aber alle Naselang ausgetauscht und leistungsfähiger werden

Insofern ist die Architektur bewusst so gestaltet, dass ein Server mit minimalen Ressourcen zum Einsatz kommen kann. Ein Web-Server reicht. Und der eibd + die CGI-Bin sind winzig klein.

PHP ist ein reines Komfort-Feature, die CV läuft auch wunderbar ohne.
Python (egal welche Version...) wird nicht mal für den Komfort benötigt.

Kommt das nicht darauf an, wie die "App" funktioniert? Sie könnte die Seiten (html?) ja auch jederzeit vom (schnellen) Flash laden, statt beim start komplett in den Flash.

Das könnte man in der CV problemlos zusätzlich implementieren (-> Offline Storage). Bisher habe ich aber noch keine groben Probleme mit der Ladezeit gehört.

Das hängt übrigens auch mit der Architektur zusammen, bzw. den Design-Prämissen:
Eine Visu lädt man 1x und dann läuft die ewig.
=> Beim Laden darf man gerne etwas Zeit investieren, solange ich beim Betrieb keine Zeit vergeude (bei einem klassischen Programm würde man hier von einer Optimierung sprechen wo man die Run-Time dadurch vermeidet, dass man möglichst viel zur Compile-Time erledigt)
=> Die Seiten werden beim Laden aufgebaut und dann im RAM gehalten
=> Beim Betrieb werden nur noch genau diese Rechenoperationen durchgeführt die zwingend und minimal notwendig sind.

Übrigens: Durch Swapping kümmert sich dann das Betriebssystem darum dass die nicht genutzten Seiten notfalls aus dem RAM vorberechnet im Dateisystem abgelegt werden. Mit maximaler (da Null Zusatzberechnungen) Geschwindigkeit wenn die wieder rein geholt werden.