VCR.NET 4.1 – Ein paar Erfahrungen bei der Erstellung des neuen Web Clients

Die Umstellung auf den neuen auf JavaScript (jQuery), HTML und REST Web Diensten basierenden Web Client von VCR.NET 4.1 ist erst einmal abgeschlossen. Es ist zwar noch einiges an Feintuning insbesondere des Layouts und Aufräumarbeiten zu leisten, aber ich erwarte nun keine grundsätzlichen Änderungen mehr. Die alten ASP.NET Web Seiten wurden vollständig deaktiviert, selbst die Startseite ist nun eine HTML Seite und wird vom Web Server nicht mehr gesondert aufbereitet.

Wie geplant habe ich mich bei der Entwicklung auf jQuery als kleinstes JavaScript Framework beschränkt – jQueryUI wird in einem sehr beschränkten Maße etwa für die Visualisierung von Schaltflächen oder der in die Seiten eingebetteten Erläuterungstexte zusätzlich genutzt. Zur Vereinfachung der Anzeige von Listen und Details zu einzelnen Listeneinträge wird ein eigener, sehr rudimentärer Vorlagenmechanismus genutzt. Dazu ein entsprechendes Gegenstück für das Binden von Werten an Eingabefelder in Formularen und der zugehörigen Validierung von Eingabedaten. Diese wenigen (vielleicht ein bis zwei Hundert) Zeilen JavaScript Code machten es so möglich, den VCR.NET 4.1 Web Client ohne die Koppelung an ein viele tausende Zeilen umfassendes Framework zu erstellen. Ich hoffe, dass es so auch in Zukunft möglich wird, den Web Client ohne allzu viel Rücksicht auf externe Komponenten weiterentwickeln zu können. Natürlich muss die Zeit zeigen, ob erweiterte Anforderungen an den Web Client nicht doch Hilfe von außen benötigen – dieses Thema wird aber erst mit VCR.NET 4.2 angegangen.

Anstelle von CSS wurde bei der Entwicklung auf LESS gesetzt, wobei ich allerdings fairer Weise sagen muss, dass ich hier nur an der Oberfläche kratze – mangels Erfahrung im UI Umfeld. Lediglich die Definition von Konstanten (für Farben, Zeichensätze, etc.) und die Schachtelung von Konfigurationen werden in einem beschränkten Umfang genutzt. Vielleicht wird es bei der nun folgenden Endphase der Entwicklung von VCR.NET 4.1 etwas mehr, aber da bin ich eher skeptisch.

Als extrem nützlich habe ich den Einsatz von TypeScript zur Entwicklung des JavaScript Client Codes empfunden – auch wenn ich hier sicher noch nicht das volle Potential ausgeschöpft habe. Die Möglichkeit der typsicheren Programmierung erweist sich immer wieder als extrem hilfreich bei der Früherkennung von Fehlbedienungen. Sehr elegant ist auch die Definition der Kommunikationsstrukturen für den Aufruf der REST Web Dienste als Schnittstellen (interface): diese erzeugen keinerlei JavaScript Code, erlauben aber trotzdem eine typsichere Programmierung wobei die Namen von Feldern einer jeden Struktur an genau einer Stelle im JavaScript Projekt festgelegt werden.

Gerade bei dem letzten Punkt habe ich allerdings auch mehrfach das Gefühl gehabt, dass JavsScript einfach mehr bietet, als durch das enge TypeScript Korsett angesprochen werden kann. Ich erhalte zum Beispiel vom Web Dienst eine Kontrollstruktur, die ich mit weiteren Feldern anreichern möchte. Dazu gibt es natürlich einige Alternativen (etwa Ausstieg aus TypeScript via any oder die Definition erweiterter Schnittstellen), die aber an die Eleganz von JavaScript nicht herankommen (einfacher Zugriff via data[‚…‘]) und zudem die Typsicherheit austricksen müssen – wer weiß, ob das dann in einer Zukunft von TypeScript überhaupt noch geht.

Was mich allerdings sehr behindert hat ist die Integration von TypeScript in Visual Studio 2012. Mein erster Ansatz war es wie aus C# et al gewohnt möglichst viele kleine, übersichtliche TypeScript Quelldateien zu verwenden – so etwa für jede Klasse eine. Beim Übersetzen kommt es aber dann dazu, dass am Ende extrem viele Prozesse gestartet werden, die den Rechner für viele Sekunden unter Volllast setzen – ich vermute, für jede TypeScript Datei mindestens ein Prozess. In VCR.NET 4.1 ist daher sämtlicher Client Code in eine einzige TypeScript Datei zusammengefasst worden. Sollte sich die Visual Studio Integration verbessern, werde ich über eine erneute Trennung in einer späteren Version nachdenken.

Bis bald

Jochen

VCR.NET 4.1 – Kontrollzentrum, Schlafzustand und Web Dienste

VCR.NET 4.1 wird keine der früheren SOAP basierten Web Schnittstellen mehr anbieten. Daher muss sich nun unter anderem auch das VCR.NET Kontrollzentrum einer anderen Art der Kommunikation bedienen – das Kontrollzentrum ist die Anwendung, die der Anwender als normalerweise farbig hinterlegtes Kamerasymbol im System Tray von Windows sieht. Weitestgehend konnte ich mich dabei auf die neuen REST Diensten stützen, die für den neuen Web Client sowieso benötigt werden. Eine Ausnahme ist dabei allerdings der automatische Übergang in den Schlafzustand, der nach abgeschlossenen Aufzeichnungen oder Aufgaben ausgelöst werden kann. Dazu hier ein wenig Hintergrundinformationen und eine kurze Vorstellung der vom Kontrollzentrum eingesetzten Methoden.

Wenn der VCR.NET Recording Service nach einer Aufzeichnung oder Aufgabe feststellt, dass keines der zugeordneten Geräte mehr in Benutzung ist, so wird intern vermerkt, dass ein Übergang in den Schlafzustand durchgeführt werden kann – natürlich nur, wenn die Konfiguration es gestattet, einen solchen Übergang auszuführen. Nun ist es aber möglich, dass ein solcher Übergang nicht unmittelbar möglich ist: pro Aufzeichnung (und Aufgabe) können so genannte Erweiterungen definiert werden, die zu einem bestimmten Zeitpunkt während der Durchführung der Aktivität als separate Windows Prozesse gestartet werden. Ich selbst nutze etwa das LIVE Demux intensiv, das bereits beim Starten einer Aufzeichnung den Demux Vorgang via ProjectX aktiviert und diesen dann parallel zur Aufzeichnung kontinuierlich durchführt. Allerdings hat diese Erweiterung auch nach Ende der Aufzeichnung eine gewisse Nachlaufzeit, die der VCR.NET Recording Service vor dem Übergang in den Schlafzustand abwartet.

Kommt es dann nun endlich an den Punkt, an dem ein Übergang in den Schlafzustand durchgeführt werden darf, so prüft VCR.NET trotzdem noch, ob Anwender interaktiv am System angemeldet sind. Ist dies der Fall, so wird der Übergang nicht durchgeführt – die Prüfung wird frühestens mit dem Ende der nächsten Aufzeichnung oder Aufgabe wiederholt. An dieser Stelle kommt nun das VCR.NET Kontrollzentrum ins Spiel.

Das Kontrollzentrum ruft periodisch den REST Web Service Info (http://rechner/vcr.net/info) via GET auf und erhält dann folgende Informationen:

  • hibernationPending: ist gesetzt, wenn ein Schlafzustand grundsätzlich ansteht.
  • extensionsRunning: ist gesetzt, wenn irgendwelche Erweiterungen aktiv sind.

Je nach Konfiguration des Kontrollzentrums erkennt dieses daraus, wenn der VCR.NET Recording Service in den Schlafzustand wechseln möchte – dies aber nicht kann, weil ja mindestens der Anwender interaktiv angemeldet ist, in dessen Namen es selbst ausgeführt wird. In einem ersten Schritt wird über ein POST auf den REST Web Dienst Hibernate (http://rechner/vcr.net/hibernate?reset) VCR.NET mitgeteilt, dass der Übergang in den Schlafzustand nun durch das Kontrollzentrum geregelt wird – der VCR.NET Recording Service setzt daraufhin die interne Markierung zurück. Das Kontrollzentrum öffnet gleichzeitig den sicher bekannten Dialog, der den Übergang in den Schlafzustand ankündigt.

Wird dieser Dialog vom Anwender nicht im konfigurierten Zeitraum geschlossen, so löst das Kontrollzentrum den Schlafzustand durch ein weiteres POST auf den Hibernate Web Dienst (http://rechner/vcr.net/hibernate?hibernate) nun endgültig aus. Dieser Vorgang wird allerdings verzögert, so lange VCR.NET meldet, dass Erweiterungen aktiv sind.

Im Endeffekt läuft die gesamte Steuerung des Schlafzustands für den Fall interaktiver Anwender also im Wesentlichen über 3 einfache Aufrufe der VCR.NET 4.1 Web Dienste. Es sollte daher auch kein Problem sein, diese Funktionalität in eigene Anwendung zu integrieren und an die eigenen Bedürfnissen anzupassen, wenn der relative starre Mechanismus des VCR.NET Kontrollzentrums nicht ausreichen sollte.

Viel Spaß

Jochen

VCR.NET 4.1 – Protokolle und anderer Kleinkram

Die funktionale (nicht optisch / technische) Umstellung des Web Clients ist nun soweit abgeschlossen. Für die bisherigen separaten Seiten zum Starten einer Aktualisierung von Programmzeitschrift oder Quellenlisten (aka Sendersuchlauf) habe ich eine minimalistische Lösung gewählt: diese vermutlich eher selten verwendeten Aktionen sind nun direkt in die Startseite des VCR.NET Recording Service integriert – natürlich nur sichtbar, wenn man den entsprechenden Verweis aktiviert:

Aktualisierung starten

Bei der Ansicht der Protokolle hat sich funktional kaum etwas getan. Wie an vielen anderen Stellen sind nun sowohl die Hilfe als auch die Detailanzeige in die Liste integriert. Den Abruf von Aufzeichnungen aus dem Web Client heraus habe ich in die Detailansicht verschoben.

Protokolle

So Long

Jochen