Re: [vdr] RfC: add encryption and compression to VDR
Hi Am Samstag, 13. November 2010 schrieb Steffen Barszus: > On Fri, 12 Nov 2010 23:10:23 +0100 > > Dieter Hametner wrote: > > The live-plugin has support (contributed by third party developer) > > for SSL connections to its internal web-server. See the README file > > in LIVE for more details. > > > > The concept how LIVE works as plugin could be generalized to provide > > a 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON > > etc. > > I like this idea a lot - additional advantage is that the access that > way should be easier for the accessing applications. > > > The general disadvantage of such an approach is, that it creates an > > 'officially unsupported' way to control VDR remotely. I mean it does > > not get 'standardized' by Klaus :) > > As long as more than one project is using this, it should be fine. Well the LIVE plugin could make use of this new infrastructure :) That could be number one but it is not a promise :) Tadi -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
Hi Am Samstag, 13. November 2010 schrieb Christian Tramnitz: > Am 13.11.2010 11:23, schrieb Klaus Schmidinger: > > However, my suggestion would be to implement authentication, encryption > > and compression as an externel "layer". Much like a proxy, which offers > > [...] > I tend to agree with Dieter (and a few comments in vdrportal)... what > the live-plugin currently does is about the fastest method of data > transfer we could possibly have, so why not build on this? > @Dieter: I haven't looked at the live internals in too much detail, for > what part is tntnet being used and would we need to reuse this for the > xml-http/JSON idea? tntnet and boost are not really common or > light-weight, is there a simpler solution for that? The functions LIVE is using from boost are header only and are AFAIK meanwhile implemented by GCC in the TR1 C++ standard library extension. Thus boost should not be considered heavy weight. With tntnet it is a bit different. Tntnet does the complete http protocol handling incl. parsing the requests and providing the html c++ integration (in some way comparable how you merge html and php, but at compile time). It is based on an additional library (cxxtools) from the same developer Tommi Mäkitalo. I just checked the web-page[1] and found out that one of the newest features of cxxtools is now native support for xmlrpc (without the need for tntnet). It will also implement the complete http server needed. Tommi was very responsive during 'main' LIVE development and I know that he continues to be as I traditionally still join the #tntnet channel on freenode. And he lives in Germany and not how one would guess from his name in Finland. I just had a conversation with him on #tntnet and he would be glad if cxxtools (which by the way I just learned also supports JSON) could be used. Well at least if this project will make it beyond the 'being an idea' phase. Regards Tadi [1] http://www.tntnet.org/ -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
On Fri, 12 Nov 2010 23:10:23 +0100 Dieter Hametner wrote: > The live-plugin has support (contributed by third party developer) > for SSL connections to its internal web-server. See the README file > in LIVE for more details. > > The concept how LIVE works as plugin could be generalized to provide > a 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON > etc. I like this idea a lot - additional advantage is that the access that way should be easier for the accessing applications. > The general disadvantage of such an approach is, that it creates an > 'officially unsupported' way to control VDR remotely. I mean it does > not get 'standardized' by Klaus :) As long as more than one project is using this, it should be fine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
Am 13.11.2010 11:23, schrieb Klaus Schmidinger: However, my suggestion would be to implement authentication, encryption and compression as an externel "layer". Much like a proxy, which offers a secure port to the outside world, and internally connects to the standard SVDRP interface of VDR. That way, all security relevant code would be separate from VDR (it's a video recorder, not "Fort Knox" ;-) and anyone going through that gateway could make full use of all SVDRP commands, including those implemented by plugins. I also thought about this but this doesn't solve: - limitation to single SVDRP connection only - (complete) epg data access rather slow - high cpu load during intensive SVDRP operations (The last one should be no offense and I'm only putting together what I've got as feedback so far and found in the vdrwiki) I tend to agree with Dieter (and a few comments in vdrportal)... what the live-plugin currently does is about the fastest method of data transfer we could possibly have, so why not build on this? @Dieter: I haven't looked at the live internals in too much detail, for what part is tntnet being used and would we need to reuse this for the xml-http/JSON idea? tntnet and boost are not really common or light-weight, is there a simpler solution for that? In regards to the proxy solution I completely agree with Klaus, but I don't want to reinvent the wheel either, so when taking into consideration Dieter's suggestion to create an universal xml-http or JSON interface this could be easily (reverse) proxied using existing solutions such as apache/mod_proxy (with the authentication part done by apache). Best regards, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
On 12.11.2010 23:10, Dieter Hametner wrote: > Hi > > Am Freitag, 12. November 2010 schrieb Christian Tramnitz: >> Right now when the needs of a vdr extension goes beyond core SVDRP >> capabilities a different approach is being used by the each extensions. >> Prominent examples are: >> - vdradmin (using native SVDRP and suffering from its performance, >> optional use of direct file access to epg data) >> - live-plugin (integrating into vdr as plugin) >> - vdr iphone remote (using native SVDRP and due the bad performance and >> encryption capabilities an optional web-based interface) >> (and I'm sure there are more) >> >> [...] > >> Now I would like to start a few discussions related to this topic, the >> ones that come to my mind mind first are: >> - Should this be implemented as plugin or in core vdr as svdrp extension? >> - Would Klaus accept patches if this will be native SVDRP? >> - Are developers/maintainers of current or feature plugins/extensions >> interested in such a solution? >> - What technical implementation would make most sense? >> - Who would be willing to contribute to such a project? >> > > The live-plugin has support (contributed by third party developer) for SSL > connections to its internal web-server. See the README file in LIVE for more > details. > > The concept how LIVE works as plugin could be generalized to provide a > 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON etc. > > The general disadvantage of such an approach is, that it creates an > 'officially unsupported' way to control VDR remotely. I mean it does not get > 'standardized' by Klaus :) Well, I don't think that Christian needs my "blessing" if he wants to implement this as a plugin ;-) However, my suggestion would be to implement authentication, encryption and compression as an externel "layer". Much like a proxy, which offers a secure port to the outside world, and internally connects to the standard SVDRP interface of VDR. That way, all security relevant code would be separate from VDR (it's a video recorder, not "Fort Knox" ;-) and anyone going through that gateway could make full use of all SVDRP commands, including those implemented by plugins. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
Hi Am Freitag, 12. November 2010 schrieb Christian Tramnitz: > Right now when the needs of a vdr extension goes beyond core SVDRP > capabilities a different approach is being used by the each extensions. > Prominent examples are: > - vdradmin (using native SVDRP and suffering from its performance, > optional use of direct file access to epg data) > - live-plugin (integrating into vdr as plugin) > - vdr iphone remote (using native SVDRP and due the bad performance and > encryption capabilities an optional web-based interface) > (and I'm sure there are more) > > [...] > Now I would like to start a few discussions related to this topic, the > ones that come to my mind mind first are: > - Should this be implemented as plugin or in core vdr as svdrp extension? > - Would Klaus accept patches if this will be native SVDRP? > - Are developers/maintainers of current or feature plugins/extensions > interested in such a solution? > - What technical implementation would make most sense? > - Who would be willing to contribute to such a project? > The live-plugin has support (contributed by third party developer) for SSL connections to its internal web-server. See the README file in LIVE for more details. The concept how LIVE works as plugin could be generalized to provide a 'generic' (SVDRP like) access via xml-http(s)-requests or via JSON etc. The general disadvantage of such an approach is, that it creates an 'officially unsupported' way to control VDR remotely. I mean it does not get 'standardized' by Klaus :) Regards Tadi -- Dieter Hametnerdh (plus) vdr (at) gekrumbel (dot) de live plugin developer http://live.vdr-developer.org signature.asc Description: This is a digitally signed message part. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RfC: add encryption and compression to VDR
On 12.11.2010 17:04, Christian Tramnitz wrote: > Right now when the needs of a vdr extension goes beyond core SVDRP > capabilities a different approach is being used by the each extensions. > Prominent examples are: > - vdradmin (using native SVDRP and suffering from its performance, > optional use of direct file access to epg data) > - live-plugin (integrating into vdr as plugin) > - vdr iphone remote (using native SVDRP and due the bad performance and > encryption capabilities an optional web-based interface) > (and I'm sure there are more) > > While this is not bad per se there is obviously room for improvement. So > my idea was to introduce a new standardized interface to VDR (either as > plugin or native SVDRP commands) to plugins/extensions offering: > - encryption (to be able to use it remotely in a more secure fashion) > - compression (to overcome performance limitations especially when large > amount of epg data have to be transferred) > - and optionally authentication for obvious reasons > > Now I would like to start a few discussions related to this topic, the > ones that come to my mind mind first are: > - Should this be implemented as plugin or in core vdr as svdrp extension? > - Would Klaus accept patches if this will be native SVDRP? No. If at all, this has to go into a plugin. > - Are developers/maintainers of current or feature plugins/extensions > interested in such a solution? > - What technical implementation would make most sense? > - Who would be willing to contribute to such a project? > > For the first step I was thinking about adding a "STARTTLS" command to > core vdr (as patch) handling encryption and maybe also tranparent > compression. This taks should be fairly easy as we could borrow ideas or > even code from existing projects using STARTTLS (like mail servers). > Authentication however would require a major redesign as far as I can tell. Definitely no authentication or encryption stuff in core VDR. Klaus > German version of this discussion can be found here: > http://www.vdrportal.de/board/thread.php?threadid=101357 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] RfC: add encryption and compression to VDR
Right now when the needs of a vdr extension goes beyond core SVDRP capabilities a different approach is being used by the each extensions. Prominent examples are: - vdradmin (using native SVDRP and suffering from its performance, optional use of direct file access to epg data) - live-plugin (integrating into vdr as plugin) - vdr iphone remote (using native SVDRP and due the bad performance and encryption capabilities an optional web-based interface) (and I'm sure there are more) While this is not bad per se there is obviously room for improvement. So my idea was to introduce a new standardized interface to VDR (either as plugin or native SVDRP commands) to plugins/extensions offering: - encryption (to be able to use it remotely in a more secure fashion) - compression (to overcome performance limitations especially when large amount of epg data have to be transferred) - and optionally authentication for obvious reasons Now I would like to start a few discussions related to this topic, the ones that come to my mind mind first are: - Should this be implemented as plugin or in core vdr as svdrp extension? - Would Klaus accept patches if this will be native SVDRP? - Are developers/maintainers of current or feature plugins/extensions interested in such a solution? - What technical implementation would make most sense? - Who would be willing to contribute to such a project? For the first step I was thinking about adding a "STARTTLS" command to core vdr (as patch) handling encryption and maybe also tranparent compression. This taks should be fairly easy as we could borrow ideas or even code from existing projects using STARTTLS (like mail servers). Authentication however would require a major redesign as far as I can tell. German version of this discussion can be found here: http://www.vdrportal.de/board/thread.php?threadid=101357 Thanks for your feedback, Christian ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
