ZitatIch wäre allerdings dafür alles in einem Source-Tree zu halten, denn dank SWIG wird es zwangsläufig darauf hinauslaufen, dass einige Daten "allgemeingültig" für alle gewünschten Scriptsprachen sind. Wäre irgendwie unsinnig die dann zwischen getrennt gepflegten Plugins immer hin und herzusyncen. Ich bin für bedingte Kompilierung und eine "Make.config" für das Plugin. So könnte sich jeder die Scriptsprachen aktivieren, die er nutzen will.
Hört sich für mich nach nem guten Plan an 
Hallo,
Zurück zum Topic:
Leider bin ich bei SWIG nie wirklich durchgestiegen. Ein Buch zum Thema "Perl Einbettung" habe ich zwar (damals extra gekauft, weil ich den VDR um Perl erweitern wollte) aber das Thema war mir dann zu komplex um es so ohne weitere Hilfe umsetzen zu können. Wenn mir voeck aber etwas zur Seite steht, würde ich bei einer Perl-Anbindung gerne helfen. Ich wäre allerdings dafür alles in einem Source-Tree zu halten, denn dank SWIG wird es zwangsläufig darauf hinauslaufen, dass einige Daten "allgemeingültig" für alle gewünschten Scriptsprachen sind. Wäre irgendwie unsinnig die dann zwischen getrennt gepflegten Plugins immer hin und herzusyncen. Ich bin für bedingte Kompilierung und eine "Make.config" für das Plugin. So könnte sich jeder die Scriptsprachen aktivieren, die er nutzen will.
genau so hatte ich mir das auch überlegt. Auf diese Weise kann jeder die Sprache wählen, die er persönlich für seine Zwecke bevorzugt. Man würde also einfach die Idee des scripting-Plugins weiterführen. Vielleicht kann man sogar direkt darauf aufbauen. Ich werde dazu mal den alten Author kontaktieren.
Ansonsten kann ich das mit SWIG sehr gerne machen. Ich werde mich da mal wieder reinarbeiten - ich habe es auch schon ein paar Jahre nicht mehr angerührt - und Interface-Dateien für die VDR-Klassen schreiben und SWIG auch direkt ins Makefile integrieren. Dann könntest du darauf direkt die Perl-Einbindung aufsetzen.
Grüße,
Sebastian
Das hört sich alles sehr gut an und auch ich bin sehr daran interessiert. Mal so auf die Schnelle ein Plugin zu schreiben ist einfach zu verlockend (kann ja auch "Rapid Prototyping" sein; wenn es funktioiniert, kann man es ja immer noch in C/C++ erstellen, wenn Performance gewünscht wird).
Ich fürchte nur, dass das mit SWIG im ersten Ansatz zu umfangreich wird (eierlegende Wollmilchsau). Gibt es Alternativen?
ZitatIch fürchte nur, dass das mit SWIG im ersten Ansatz zu umfangreich wird
Habe inzwischen SWIG mal überflogen und wenn ich es richtig verstanden habe, dann bedeutet SWIG genau das Gegenteil des Threadtitels.
Bei SWIG wird nicht python in den VDR eingebunden, sondern eine VDR-Bibliothek wird dem Python-Interpreter mittels zu schreibender Wrapper-Funktionen einverleibt.
Ich kann mir nicht so richtig vorstellen, dass das im Sinne des Thread-Starters ist.
Die VDR-Bibliothek, die per SWIG in Scripten verwendet werden könnte, liefe ja dann im Prozess-Kontext des Script-Interpreters und hat keine Verbindung zum VDR und schon garnicht zu den internen Daten des VDR.
Ich hatte den Thread-Starter so verstanden, dass Scripte als VDR-Plugins laufen sollten - dazu müsste aber der Interpreter in den VDR eingebunden werden.
Nur mal so als Denkanstoß: wäre es für Scripte nicht sinniger, man würde im VDR Unterstützung für das Sys-FS analog zum Linux-Kernel einbauen?
Dann hätte der VDR die Hoheit über die Daten und könnte selber festlegen, welche Daten geschrieben und welche nur gelesen werden dürfen.
... und das Sysfs wäre für jedes Script lesbar (so es denn die Berechtigung erhält) und enthielte Echtzeit-Daten.
Gut, damit wären keine Scripte als VDR-Plugin möglich, aber ich bin an der Ecke sowieso eher fantasielos 
Vielleicht wäre es auch sinniger, man würde erst mal zusammentragen, was denn so ein Script-Plugin können soll, oder welche Funktionalität wo fehlt. Dann ließe sich vielleicht eher ein sinnvoller Weg finden.
Gruß Gero
Moin!
Nur mal so als Eigen-Werbung: mit meinem dbus2vdr-Plugin kann man auch ganz wunderbar von python aus auf die "Innereien" des vdr zugreifen (zumindest die Theorie, ich kann kein python).
Es ist zwar noch nicht all zu viel implementiert, aber wann immer etwas gebraucht wird, lässt es sich einbauen.
Das hat den Vorteil, dass das "Plugin" in einem eigenen Prozess läuft und bei einem Absturz nicht gleich den ganzen vdr mit sich zieht.
Und wie oben schon erwähnt gibt es auch noch restfulapi. Wie leicht da der Zugriff von Scriptsprachen aus ist, kann ich aber nicht beurteilen.
Lars.
Hallo,
ZitatBei SWIG wird nicht python in den VDR eingebunden, sondern eine VDR-Bibliothek wird dem Python-Interpreter mittels zu schreibender
Wrapper-Funktionen einverleibt.
Ich kann mir nicht so richtig vorstellen, dass das im Sinne des Thread-Starters ist. Die VDR-Bibliothek, die per SWIG in Scripten verwendet werden könnte,
liefe ja dann im Prozess-Kontext des Script-Interpreters und hat keine Verbindung zum VDR und schon garnicht zu den internen Daten des VDR.
Ich hatte den Thread-Starter so verstanden, dass Scripte als VDR-Plugins laufen sollten - dazu müsste aber der Interpreter in den VDR
eingebunden werden.
das ist nicht ganz korrekt. Es stimmt, dass SWIG letztendlich C++-Klassen oder -Funktionen in Python-Module wrappt. Diese Module können auch ganz normal in einem externen Interpreter geladen werden. Der Interpreter lädt dazu das Modul - eine Shared Library - und führt eine wohl definierte Funktion darin aus. Im Falle des eingebettetem Interpreter, kann man nun beim Initialisieren einfach eine Reihe von Modul-Init-Funktionen übergeben, die dieser dann automatisch lädt. Und genau so hatte ich es vor zu machen, der Code des Python-Modul wäre auf diese Weise in das VDR-Plugin gelinkt. Das funktioniert bei allen SWIG-Alternativen, die ich mir vorher angeschaut hatte (Boost.Python, SIP). Und daher gehe ich ganz stark davon aus, dass es mit SWIG auch funktioniert.
Ob sich allerdings ein eingebetteter Perl-Interpreter auch auf diese Weise erweitern lässt, kann ich nicht sagen. Aber ich vermute es irgendwie.
Sebastian
Wie leicht da der Zugriff von Scriptsprachen aus ist, kann ich aber nicht beurteilen.
Ich hatte da mal ein bisschen experimentiert: https://github.com/seahawk1986/pyrestfulapi muss das aber mal wieder auf den aktuellen Stand von restfulapi anpassen wenn ich Zeit habe...
Nur mal so als Eigen-Werbung: mit meinem dbus2vdr-Plugin kann man auch ganz wunderbar von python aus auf die "Innereien" des vdr zugreifen (zumindest die Theorie, ich kann kein python).
Es ist zwar noch nicht all zu viel implementiert, aber wann immer etwas gebraucht wird, lässt es sich einbauen.
Das hat den Vorteil, dass das "Plugin" in einem eigenen Prozess läuft und bei einem Absturz nicht gleich den ganzen vdr mit sich zieht.
Das Plugin habe ich auch schon gesehen und ich finde es eine sehr gute Idee. Aber für die Anwendung, die ich im Sinn habe, nicht ganz ausreichend.
Allerdings spiele ich mit dem Gedanken mich damit auch ein wenig näher zu beschäftigen. Vielleicht bastele ich mal ein paar Bindings dafür (Python und/oder Qt).
Sebastian
Moin!
Das Plugin habe ich auch schon gesehen und ich finde es eine sehr gute Idee. Aber für die Anwendung, die ich im Sinn habe, nicht ganz ausreichend.
Ja, momentan ist es eigentlich nur für einen Zugriff von außen konzipiert, aber eventuell werde ich es mal fit machen, um Signale nach außen zu senden (ähnlich dem dbus-Plugin).
Auch das Housekeeping etc. nach außen zu tragen sollte nicht schwierig werden.
Ein Binding für Python sollte eigentlich nicht nötig sein, oder?
Siehe https://github.com/flensrocker…master/bin/dbus-client.py
Ich versuche, die "introspect"-Ausgaben möglichst korrekt und aktuell zu halten, vielleicht schaust du dir mal sowas wie dbus-binding-tool o.ä. an.
Es sollte möglich sein, die Bindings automatisch generieren zu lassen. Man muss sich ja nicht mehr Arbeit machen als nötig. Insbesondere, weil das Plugin (hoffentlich) ständig erweitert wird. 
Lars.
Ein Binding für Python sollte eigentlich nicht nötig sein, oder?
Siehe https://github.com/flensrocker/vdr-plugi…/dbus-client.py
Ich versuche, die "introspect"-Ausgaben möglichst korrekt und aktuell zu halten, vielleicht schaust du dir mal sowas wie dbus-binding-tool o.ä. an. Es sollte möglich sein, die Bindings automatisch generieren zu lassen. Man muss sich ja nicht mehr Arbeit machen als nötig. Insbesondere, weil das Plugin (hoffentlich) ständig erweitert wird.
Oh, dann ist ja sogar noch einfacher als gedacht. Dann werde ich mir das
natürlich sparen und bei Gelegenheit mal direkt mit dem Plugin
rumspielen.
Sebastian
Moin!
Oh, dann ist ja sogar noch einfacher als gedacht. Dann werde ich mir das
natürlich sparen und bei Gelegenheit mal direkt mit dem Plugin
rumspielen.
Vergiss bitte nicht, da das Plugin den System-Bus benutzen möchte, die entsprechende Rechtedatei nach /etc/dbus-1/system.d zu kopieren und anzupassen.
Sonst funktioniert der Zugriff nicht.
https://github.com/flensrocker…ster/etc/de.tvdr.vdr.conf
Lars.
Hi,
ich bin total begeistert von der Richtung, die diese Diskussion genommen hat
Bestätigt mich mal wieder in der Einstellung, dass man nicht genug öffentliche Schnittstellen unterstützen kann.
Gruß Gero
Für mich fühlt es sich jetzt eher so an als wäre die Diskussion im Sande verlaufen. Sind aber nur meine zwei EUR Cent.
Aber um mal dem Diskussionsverlauf zu folgen: Kann denn dieses "dbus2vdr" bereits das GUI bedienen? Also einmal "mache offenes GUI mit Listenauswahl und folgenden Einträgen und sag mir was der Benutzer da auswählt".
Nebenbei bemerkt: dbus ist von freedesktop und bisher habe ich die vor allem im Zusammenhang mit Sicherheitslücken in Erinnerung. Bin mal gespannt wann dieses dbus als "globale Kommunikationsschnittstelle" das erste mal negativ auffällt.
Kann denn dieses "dbus2vdr" bereits das GUI bedienen? Also einmal "mache offenes GUI mit Listenauswahl und folgenden Einträgen und sag mir was der Benutzer da auswählt".
Das kanns nicht, das kann das osdserver Plugin. Vodcatcher-helper (ein Java Programm) nutzt das z.B. um sich als Plugin in den VDR einzubinden.
cu
Und den Rest kann SVDRP auch. Ist natürlich Geschmackssache wie man mit dem VDR spricht. Für SVDRP braucht es halt kein zusätzliches Plugin.
Und den Rest kann SVDRP auch.
Nicht wirklich, man merkt bei svdrp schon extrem das es nicht für heftige Nutzung gedacht ist, über dbus läufts schon flüssiger. Klar, alle paar Minuten mal ne svdrp Abfrage leistet svdrp auch.
Aber wenn man innherhalb von 60 Sekunden dort 200 EPG Einträge ausliest und zurückschreibt (bei mit beijedem Suchtimerupdate) dann merkt man schon das die Fernbedienung (die bei mir teilweise auch über svdrp läuft) aufeinmal nicht mehr vernünftig geht.
cu
Für mich fühlt es sich jetzt eher so an als wäre die Diskussion im Sande verlaufen. Sind aber nur meine zwei EUR Cent.
Hier ist gar nichts im Sande verlaufen. Ich habe nur gesagt, dass dbus2vdr nicht für die Anwendungen, die ich im Sinne habe, geeignet ist. Aber es ist doch eine interessante Schnittstelle zum VDR, mit der ich mich auch irgendwann einmal gerne beschäftigen würde.
Bei der Skripting-Sache werde ich jetzt einfach weitermachen wie geplant. Nur mit der Änderung, dass ich versuche SWIG zu verwenden, damit man eventuell das Ganze später in ein generelles Skripting-Plugin integrieren kann, das dann z.B. auch Perl unterstützt.
Ok, dann zieh ich meinen Begeisterungsausruf zurück.
Für mich sah es so aus, als würden mini73 und voeck zusammen arbeiten. Das hätte mir gefreut.
Also denn ... weiterhin jeder für sich ...
Moin!
Also einmal "mache offenes GUI mit Listenauswahl und folgenden Einträgen und sag mir was der Benutzer da auswählt".
Meinst du, dass das OSD mit einer Liste von Texten aufgehen soll und falls der Benutzer etwas auswählt, soll z.B. der Index zurückgegeben werden?
Da muss man allerdings bedenken, dass diverse Timeouts zuschlagen können (vom OSD, von dbus usw.).
Oder man müsste es asynchron implementieren. Ich schau mal...
Nur aus Neugier: was für einen Anwendungsfall stellst du dir vor?
Ich möchte jetzt aber nicht den Thread hijacken, wir können darüber hier weiter reden.
Lars.
Nur aus Neugier: was für einen Anwendungsfall stellst du dir vor?
Ich bin zwar nicht angesprochen, aber um mal zu zeigen das sowas tatsächlich genutzt wird... das vodcatcher-helper Programm nutzt das.
Ansonsten ist sowas haupsächlich ganz nett für schnelle individuelle Scriptbasteleien. Z.B. ne Liste aller PCs im LAN mit ihren momentanen Zustand anzuzeigen und auf Wunsch einzelne zu wecken.
Wobei ich jezt nicht ganz verstehe wie das Theme hier auf einmal reinkommt, das leistet doch schon das osdserver Plugin ganz hervoragend.
cu
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
