[ANNOUNCE] vdr-restfulapi 0.1.0

BTW: Wie ich oben weiter schon schrieb erhielt ich bei channels und recordings ein "Not enough space", das war ein fehlerhaftes info.vdr und ein Kanalname in der channels.conf ("FRANCE Ô").
Es war etwas mühselig diese Fehler zu finden (habe nen esyslog in std::string StringExtension::encodeToXml gepackt). Es wäre schön wenn solche Fehler im Syslog auftauchen würden.

Zitat von gda

Bei uns geht live. Hol dir doch mal unsere Paketsourcen und probiere es damit.

Stimmt, wäre ein Versuch wert, evtl. ist meine Version zu neu? Probiere ich dann mal.

cu

Moin!

Zitat von Razorblade

Super das sich da endlich mal jemand rangetraut hat, hatte das ja vor einiger Zeit schonmal vorgeschlagen
... aber bisher noch keine Zeit für die Umsetzung gefunden (jaja "nächster Winter")

Naja, mit verschlüsselter Verbindung bzw. komprimierter Übertragung hat das erst mal nichts zu tun. Jeder, der Zugriff auf den Port hat, kann den vdr programmieren.
Für dieses Problem stelle ich mir einen Apache vor, der als Proxy arbeitet und per SSL mit Client Certificate Authentication ein paar Ports an die entsprechenden Dienste weiterleitet (die dann z.B. nur noch auf localhost lauschen). Drüber nachgedacht hab ich schon, aber noch nicht angefangen, ist ja noch nicht Winter. Damit hätte man eine vdr-unabhängige Lösung. Aber das ist hier offtopic.

Zitat von Razorblade

Werds mir bei Gelegenheit mal angucken. Als mögliche Anwendung sehe ich z.B. "offline" Versionen von VDRadmin / Live-plugin auf einem "lightweight" Device (z.B. Fritzbox) ohne laufenden VDR. Das ganze kombiniert mit WOL für den (Aufnahme-VDR) und der brauch wirklich nur während einer Aufnahme laufen...

Da es ein vdr-Plugin ist, muss schon irgendwo ein vdr laufen. "Offline" geht nicht...

Lars.

Zitat von Razorblade

Für dieses Problem stelle ich mir einen Apache vor, der als Proxy arbeitet und per SSL mit Client Certificate Authentication ein paar Ports an die entsprechenden Dienste weiterleitet (die dann z.B. nur noch auf localhost lauschen). Drüber nachgedacht hab ich schon, aber noch nicht angefangen, ist ja noch nicht Winter. Damit hätte man eine vdr-unabhängige Lösung. Aber das ist hier offtopic.

Nginx! Siehe meine alten Postings im internen yaVDR-Forum.

Gruß
hepi

Zitat von mini73

Naja, mit verschlüsselter Verbindung bzw. komprimierter Übertragung hat das erst mal nichts zu tun. Jeder, der Zugriff auf den Port hat, kann den vdr programmieren.
Für dieses Problem stelle ich mir einen Apache vor, der als Proxy arbeitet und per SSL mit Client Certificate Authentication ein paar Ports an die entsprechenden Dienste weiterleitet (die dann z.B. nur noch auf localhost lauschen).

Ja genau, sobald es http ist kann man sowas ja sehr einfach selbst machen.

Zitat von mini73

Da es ein vdr-Plugin ist, muss schon irgendwo ein vdr laufen. "Offline" geht nicht...

Als ich das damals auf der Mailingliste vorgeschlagen hatte, hat tadi geantwortet:

Zitat

Well the LIVE plugin could make use of this new infrastructure That could
be number one but it is not a promise

Letztendlich macht das Live Plugin ja nichts anderes als sich über ein Plugin Interface (was sich jetzt mit restful API erledigen lassen könnte) auf vdr-Interna zuzugreifen...

Ja es wäre denkbar damit Live ausserhalb des VDR zu re-implemntieren

Moin!

Ja, z.B. als reine Javascript-Anwendung im Browser. Ich hab auch ganz viele tolle Ideen, diese API zu nutzen, nur leider noch keine Zeit...

Lars.

Zitat von mini73

Ja, z.B. als reine Javascript-Anwendung im Browser. Ich hab auch ganz viele tolle Ideen, diese API zu nutzen, nur leider noch keine Zeit...

Deshalb hat das ursprüngliche Plugin ja auch JSON ausgegeben :D.

Beim Proxy nehme ich lieber Lighttpd. Ist deutlich schlanker als Apache und sehr viel einfacher zu konfigurieren als NGINX.

Gerald

HTML OSD on CSS Gradients...

Anmerkung: Auch wenn die Buttons noch so bunt, es ist nur zum Anschauen und nicht zum Anklicken...

Spaß macht's trotzdem, auch wenn auf diese Weise nie ein Web-OSD zum Bedienen herauskommt. Es geht nur um die Möglichkeiten von CSS.

Gruß
hepi

Ich hätte da noch eine Frage zum Timerupdate:
Laut Doku soll man ja einen PUT auf http://<ip>:<port>/timers machen und im Body timer_id=<timer_id>&<geänderte Parameter> angeben:

timer_id=C-71-71-61920:0:1324681200:1400:1615&start=2015&stop=2230

Mit der httprequest.jar klappt das auch wunderbar.
Wenn ich allerdings Pythons urllib.urlencode auf die <timer_id> loslasse, erzeugt er soetwas:

>>> urllib.urlencode({'start': '1605', 'timer_id': u'T-8468-12290-32:0:1311890400:1600:1620'})
start=1605&timer_id=T-8468-12290-32%3A0%3A1311890400%3A1600%3A1620

Und meldet bei der PUT Anfrage:

Zitat

HTTPError: HTTP Error 403: The following parameters aren't valid: timer_id!

Ich vermute stark, dass urllib.encode da anders bei den Doppelpunkten vorgeht als das java-Testprogramm - wie sieht denn ein von dem Programm erzeugter Body aus?

Ich wusste es, auf die Art lockt man die Künstler an :D.

Zitat

Spaß macht's trotzdem, auch wenn auf diese Weise nie ein Web-OSD zum Bedienen herauskommt. Es geht nur um die Möglichkeiten von CSS.

Fehlt doch nur ein bisschen JavaScript, oder?

Gerald

Zitat von gda

Fehlt doch nur ein bisschen JavaScript, oder?

Ja. Aber die Frage ist, ob wir restfulapi selbst zum Web-Application-Server aufbohren wollen oder die Applikationen getrennt verwalten wollen vom Plugin.

Gruß
hepi

Wenn schon mal jemand mit nem pre 1.7.18 spielen will. Ist aber noch nicht gegen einen Vanilla vdr getestet.

cu

Zitat von hepi

Ja. Aber die Frage ist, ob wir restfulapi selbst zum Web-Application-Server aufbohren wollen oder die Applikationen getrennt verwalten wollen vom Plugin.

Das sehe ich ähnlich. Das OSD gehört nicht ins restful, auch wenn an sich klasse ist. Lieber ein webosd-plugin

V_R

Lieber eine Webapplikation in Verbindung mit dem Plugin

Ein Problem von mir ist momentan die bündige Textformatierung im HTML-OSD: Irgendwann stösst CSS an seine Grenzen, wenn die Textstrings mit Tabulatoren formatiert werden sollen. Ich mache dann

white-space: pre;

Dann bleiben Tabulatoren erhalten. In manchen OSD-Zeilen stecken aber zweispaltige Darstellungen (= ein Tabulator im String), bei anderen OSD-Zeilen haben wir dreispaltige Darstellungen (=zwei Tabulatoren).

Ich kann nun die Tabulator-Breite verändern über -moz-tab-size, aber damit kriege ich nicht überall die erwünschten Ergebnisse.

Per Javascript könnte ich nun die Strings an den Stellen splitten, wo Tabulatoren auftreten. Optimal wäre aber, wenn im JSON schon nach Tabulatoren vorgetrennt werden könnte.

aelo: Hast Du darüber schon nachgedacht? Wäre das sinnvoll?

Gruß
hepi

Zitat von hepi

Ein Problem von mir ist momentan die bündige Textformatierung im HTML-OSD: Irgendwann stösst CSS an seine Grenzen, wenn die Textstrings mit Tabulatoren formatiert werden sollen. Ich mache dann

white-space: pre;

Dann bleiben Tabulatoren erhalten. In manchen OSD-Zeilen stecken aber zweispaltige Darstellungen (= ein Tabulator im String), bei anderen OSD-Zeilen haben wir dreispaltige Darstellungen (=zwei Tabulatoren).

Ich kann nun die Tabulator-Breite verändern über -moz-tab-size, aber damit kriege ich nicht überall die erwünschten Ergebnisse.

Wäre es nicht sinniger die Strings bereits im Plugin aufzusplitten (Element Zeile mit Unterelementen Spalte1, Spalte2 usw. Also als ul innherhalb des li) und dann die Breite der li per CSS zu Formatieren? Der Tabulator gehört doch eigentlich eh nicht zu den Nutzdaten sondern definiert eher die Struktur der Daten.
(-moz-tab-size und Co. ist doch eh Tabu, oder nicht?)
Wobei es eh nen CSS Framework braucht wenns wirklich brauchbar (alle Browser inklusive ihren CSS Bugs) werden soll.

cu

Da vdr-restfulapi die SVN Version von cxxtolls benötigt und damit aber das live-Plugin nicht mehr geht, ist dieses Plugin für mich ganz einfach unbrauchbar.

Zitat von C-3PO

Da vdr-restfulapi die SVN Version von cxxtolls benötigt und damit aber das live-Plugin nicht mehr geht

Wobei der Punkt noch zu klären wäre, weil bei yaVDR geht ja offenbar beides zusammen.

Aber schön zu hören das du die selben Probleme hast Damit schliesse ich dann erstmal aus das ich da irgendenen blöden Fehler gemacht habe.

@yaVDR Nutzer, welche live Version ist dann hier als funktionieren bekannt? Im PPA sind ja mehere Packete.
OK, geklärt, das gibts nur das vom cvs20110323 ohne yaVDR patches.

cu

Für mich hat sich das schon geklärt.
Das ganze Plugin ist mir viel zu ya-lastig und somit für mich uninteressant.

Das ganze Plugin ist mir viel zu ya-lasastig und somit für mich uninteressant

ya-lasastig ?
ya-salat ?

no one can reach c3po the water