Da eine öffentliche Testversion des DVB.NET / VCR.NET Paketes in der Version 4.1 bevorsteht, habe ich den Support für alle älteren Versionen wie üblich eingestellt. Ich hoffe, dass es nicht jetzt noch zu schweren Problemen kommt, die zeitnah gelöst werden müssen.
Jochen
… aber noch nicht ganz.
Ich habe im Downloadbereich ein neues Paket für sehr frühe Tests bereitgestellt. Dieses umfasst eine echte Version 4.1 von DVB.NET (Bibliothek, Server und Werkzeuge, kann unbeschränkt parallel zu früheren Versionen von DVB.NET installiert werden, falls diese nicht antiquar sind), dem DVB.NET / VCR.NET Viewer (der im VCR.NET Verbindungsmodus nicht mit VCR.NET Versionen vor 4.1 zusammenarbeiten kann) und dem VCR.NET Recording Service (der nicht mehr mit dem Viewer vor Version 4.1 kommunizieren kann). Wie bisher kann nur eine VCR.NET Version pro Rechner installiert werden und auch wenn eine Parallelinstallation von verschiedenen Versionen des Viewers möglich ist empfiehlt es sich, immer nur eine davon installiert zu haben.
Sollte man irgendeine Art von Verteilung einsetzen, wie etwa mehrere Rechner mit VCR.NET Recording Service oder auch nur das VCR.NET Kontrollzentrum auf einem separaten Rechner, so ist strikt darauf zu achten, dass alle gemeinsam genutzten Versionen von VCR.NET und Viewer identisch sind.
Ich habe als Downloadnamen bewusst den Begriff Alpha verwendet: ich habe genau diese Version selbst heute erst in Betrieb genommen – natürlich Vorabversionen schon etwas länger, aber heute ist DVB.NET erst wirklich in die Version 4.1 aufgestiegen. Es ist durchaus mit Fehlverhalten auch schwerer Art zu rechnen. Zudem ist die Version in vielen Aspekten noch nicht rund, vor allem im Web Client: kann man über kleinere Layout Probleme noch hinweg sehen, so passt die aktuelle Hilfe noch nicht so recht zu der neuen Oberfläche. Ich möchte erst vor allem die Fragen & Antworten auf einen aktuellen Stand bringen, bevor ich eine öffentliche Beta Testversion herausgebe.
Über das Mittesten auf eigene Gefahr würde ich mich natürlich sehr freuen. Ich schlage dann folgende Vorsichtsmaßnahme vor, die ich auch selbst getroffen habe: nach der Deinstallation von VCR.NET 4.0 (oder früher) das verbleibende Installationsverzeichnis sichern – etwa in einem ZIP Archiv. Allerdings sollte das Verzeichnis selbst wie nach der Deinstallation hinterlassen verbleiben und keinesfalls gelöscht werden, da auch VCR.NET 4.1 eine automatisch Übernahme der Konfiguration und programmierten Aufzeichnungen unterstützt – ohne das Verzeichnis gäbe es dazu keine Informationen mehr. Ein besonderes Risiko stellen zurzeit übrigens 64Bit Betriebssystemumgebungen dar, da ich diese selbst nicht teste – in Rücksicht auf meine betagte Nexus-S.
Aufgrund der eigenen parallelen Nutzung eines Rechners mit Windows XP wurden die Systemvoraussetzungen übrigens nicht so verändert, wie ursprünglich geplant: das DVB.NET / VCR.NET Paket verwendet weiterhin Microsoft .NET 4.0 und nicht 4.5.
Das soll erst einmal reichen, hoffentlich bald mehr
Jochen
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 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:
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
