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
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
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
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
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
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
On Fri, 12 Nov 2010 23:10:23 +0100 Dieter Hametner dh+vdr@gekrumbel.de 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.
Hi
Am Samstag, 13. November 2010 schrieb Steffen Barszus:
On Fri, 12 Nov 2010 23:10:23 +0100
Dieter Hametner dh+vdr@gekrumbel.de 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
-
Christian Tramnitz -
Dieter Hametner -
Klaus Schmidinger -
Steffen Barszus