ZitatEine der Ideen ist jetzt, dass die VDRs ihre Resourcen austauschen und die Timer optimal verteilen.
Hm, das ist eine überaus interessante Idee, allerdings sehe ich deren Einsatz eher bei handverlesenen Powerusern.
Weiß nicht wieviele Anwender mehrere VDRs parallel mit Aufnahme-Devices betreiben.
Ich denke, die Zahl der Anwender mit echtem C/S Bedarf dürfte deutlich höher sein. Kann aber sein, dass ich da falsch liege.
Wie auch immer - ich halte das für keinen Widerspruch zum dem was ich schrieb. Wenn man den jetzigen VDR aufteilt in einzelne lauffähige Komponenten könnte das Aufnahme-Modul trotzdem ein Resourcen-Sharing betreiben, bzw. noch besser: es konnte in ein Resourcensharing eingebunden werden. Ähnlich wie die Konfiguration von div. Clients würde ich die Verwaltung der Resourcen auch von einem separaten Dienst steuern lassen.
In meinem beruflichen Umfeld hat es sich bewährt, lauffähige Komponenten mit kleinem Fokus zu erstellen. So ist das Gesamtsystem beliebig skalierbar. Dienste können mehrfach aufgesetzt werden, nur mit leicht unterschiedlichem Fokus. Das Prinzip übersetzt in den VDR-Kontext würde heißen, es gäbe einen Aufnahmedienst, der von einem Transponder aufnehmen kann. Bei einer Maschine startet der Timer-Manager den Aufnahmedienst für jede Aufnahme.
Wer jetzt das System skalieren will, könnte (im anderen Extrem) für jeden Transponder einen separaten Aufnahmedienst starten (hier können mehrere Maschinen ihre Dienste im Netz anmelden). Der Timer-Manager triggert dann nur noch die Aufnahmedienste der entsprechenden Transponder.
In meinem beruflichen Umfeld hat sich eine zentrale Datenbank als Triggerbasis bewährt (ich habe das Prinzip auch bei VdrAssistant so umgesetzt). So können Dienste als Automaten laufen und die Synchronisation der Prozesse erfolgt über Statusfelder in den Datenbanktabellen. Zusätzlich lassen sich einzelne Prozesse auch auf unterschiedliche Rechner verteilen.
Eine Aufnahme über mehrere Prozesse und Rechner könnte so ablaufen:
- epgsearch erstellt einen Timer
- der Aufnahmedienst für den Transponder des Timers ändert zum Aktivierungszeitpunkt den Status des Timers und erstellt ein Aufnahmeobjekt mit Status "in Arbeit". Daneben wird die Aufnahme auf Platte gespült. Wenn der Aufnahmedienst fertig hat, wird der Status von Timer und Aufnahmeobjekt weiter geschrieben
- ein Werbungssuchdienst könnte sich die erste fertige Aufnahme krallen (Status weiterschreiben) und nach Werbeblöcken suchen. Nach Erstellung der Schnittmarken wird der Status der Aufnahme fortgeschrieben.
- ein Serien-Verwaltungsdienst könnte die Aufnahme nach einer passenden Namensregel umbenennen, nach zusätzlichen Informationen bei den netten Indern anfragen, etc.
- ein Archivierungsdienst könnte jetzt die Aufnahme auf einen anderen Rechner verschieben ... (natürlich auch wieder unter Veränderung des Status)
Diese Dienste könnten alle auf einer Maschine laufen oder alle auf unterschiedlichen Maschinen. Natürlich könnten manche Dienste auch mehrfach gestartet werden, um parallele Arbeiten zu verrichten. Jeder Dienst sieht nur die Objekte mit seinem Eingangsstatus.
Grundsatzfrage für ein Resourcensharing ist auch die Datenhaltung: will ich dezentrale Datenhaltung oder bevorzuge ich zentrale Datenhaltung und kann so meine Hardware optimal abstimmen/einsetzen.
ZitatWas ich aber ernst meinte sind die "kruden komplexen Entwickler Vorstellung", die hier leider schon wieder bei einigen durchlinsen.
Im Gegensatz zum shitstorm bedeutet brainstorming ja gerade, dass man unausgegorene Ideen zur Diskussion stellen kann.
Solche Ideen sind deshalb ja nicht verwerflich, weil sie noch nicht ausgegoren sind.
Oft sind es gerade solche Ideen, die über die Diskussion zu ganz neuer Funktionalität führen, die man sich im Vorfeld garnicht hätte erträumen können.
Gruß Gero