Idee zur Lösung des TTS/Vista-Prob

Hallo,
Das wg der hier beschriebenen Problematik keine direkte TTS-Ausgabe mehr unter Vista und Co erfolgen kann, ist klar. Aber vielleicht muß sie das ja auch nicht und es könnte viel einfacher gelöst werden unter Umgehung der hindernden Effekte. Gleichzeitig würde einer der Hauptgründe für den Einsatz des (jetzt in V2.0 ja fehlenden) Variablen-Exchange entfallen und die Architektur dieser Informationsströme würde ein wenig „bereinigt“.

Das bisher als Workaround vorgeschlagene Generieren und Verwenden von Files und Mediaplayer ist sicher machbar, jedoch recht umständlich und wenig flexibel. So man einmal kennengelernt hat, Texte direkt als Strings in Variablen zu erzeugen und diese linear auszugeben, möchte man das auch nicht mehr missen. Außerdem stünde IPS so ein vereinfachtes Handling sicher sehr gut zu Gesicht.

Die Idee:
Eigentlich braucht doch gar niemand eine Sprachausgabe (damit meine ich jetzt die Schnittstelle zu TTS) auf dem Server, also durch den Windows-Dienst generiert.

Gebraucht wird diese, ebenso wie auch die optischen / grafischen Ausgaben auf dem Client. Und diese Software ist kein Windows-Dienst und sollte das aus Windows-Rechte-Sicht sehr wohl weiter dürfen und können.

Gebraucht würde also ein Designer-/Dashboard-Objekt, das wie ehemals das serverseitige IPS-V1-TTS-Objekt einen String-Variablen Inhalt lesen und jetzt aber ans lokal installierte TTS, also auf dem Client-PC ausgeben würde.

Werden Server und Client auf dem gleichen Gerät installiert und betrieben, ändert sich de facto gar nichts. Der PC, auf dem auch die Kernmodule laufen, babbelt fleißig wieder vor sich hin. Natürlich nur, so dort dann auch eine User-Session nebst einer Dashboard-Anwendung gestartet ist für interaktive Arbeit (hier akustischer Output), was aber aus Windows-User-Sicherheits-Sicht 100% korrekt wäre. Gehen wir davon aus, das derartige 1-PC-Lösungen auch die Visualisierung dort betreiben, ist das ohnehin gegeben.

Für Remote-Clients gilt das ebenso. Nur wenn dort „interaktiv“ eine Visualisierung läuft, kommt auch Sprache. Remote-Clients haben es mit dieser Lösung nebenbei noch einfacher:

Nebenbei entfiele auch der „Grund für TTS-Variablenaustausch“ zwischen IPS-Server- und Remote-Client-PCs. In V1 mußte, um z.B. remote im Büro die Akustikmeldungen des Servers zu hören, nochmals der Kernel laufen und per Variablen-Exchange die TTS-Outputvariable beziehen. Eigentlich war das schon ebenso ein Anachronismus, einen derartigen Server-Aufwand allein für die Ausgabe per (akustischer) Userschnittstelle am Client zu betreiben. Das könnte nun komplett entfallen, da direkt auf die (auf dem Server befindlichen) Variablen zugegriffen wird.

Für die Webschnittstelle wiederum könnte es dann ein ähnliches gekapseltes Objekt geben, das dann aber auch ohne TTS auskommen müßte (so nicht jeder Browser-PC auch TTS installiert haben sollte nebst Mime-Typ usw um das anzusprechen). Hier würde dann wohl wirklich nur noch ein intern filegenerierendes Modul in Frage kommen, das aber browserseitig -wie dort üblich- einen direkten Output-Stream abgegeben würde. Browserintern werden dann automatisch die clientseitig vorhandenen Ausgaben (Medialayer, Real, Quicktime o.ä.) angesprochen.

Aber auch an diesem Modul sollte es aus Sicht der einfachen Handhabung dann möglich sein, so ein virtuelles „Akustikoutputobjekt“ gekapselt direkt aus Variablen zu versorgen. Da das aber wiederum auf dem Server (=HTTP-Server) erfolgen würde, ist dazu eigentlich nur ein Zusammenfassen des bisherigen Workaround (Filegenerierung) in ein Script bzw eine „(virtuelle) Instanz“ o.ä. notwendig, die nur im Weboutput nutzbar ist und dort den Audio-Stream abgibt.


Final gäbe es dann:

  • im Dashboard Variablen-Input / ein clientseitiges TTS-Output-Objekt
  • serverseitig fürs Web ein Variablen-Input / Stream-Output-Script/-Objekt

…und alle Kernel-Installationen auf Remote-Client-PCs nur wegen TTS-Output nebst dafür nötigem Variablen-Exchange könnten entfallen. :slight_smile:

Nebenbei wird die Architektur ein wenig auf die Füße gestellt und damit auch wieder den normalen Security-Anforderungen der Betriebssysteme entsprochen.

Das nur mal so als Idee
Gerd