[vdr] Client/server implementation after VDR 2.0: Do not reinvent the whole wheel

Gero geronimo013 at gmx.de
Thu Mar 1 20:13:28 CET 2012

On Thursday 01 March 2012 - 17:45:02, Paul Menzel wrote:
> Am Donnerstag, den 01.03.2012, 15:31 +0100 schrieb Gero:
> > On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote:
> > > On Thursday 01 March 2012 - 07:03:03, VDR User wrote:
> > > 
> > > I just want to throw in, that there are several programs already using
> > > a client/server approach (MythTV [1], Tvheadend [2], …) and we should
> > > not reinvent the wheel when designing the new implementation.
> > 
> > I'd like to oppose headline and last statement.
> > 
> > "We" can do better, so let's go ahead :)
> It looks like my message was not clear enough. I meant we should look at
> what other projects implemented and tried and take the good ideas and
> use those. So of course the result will probably be better.

I believe, the better way would be, collect all requirements and wishes and 
start from scratch without caring about existing code (no matter wether it is 
vdr-code or other code). Current vdr already contains most functionality, so 
code needs "only" to be structured in a different way.

Most lowlevel functionality of vdr is good and I don't see the need to look at 
other projects.

What needs to be rewritten is the higher level application code and starting 
from scratch opens the chance to establish a clean design, that is flexible 
enuf for future requirements. 
Existing plugins will - of cause - be broken, but starting them from scratch 
with the new archtecture will be faster than first development.

> But cooperation like on using already existing protocols would be a big
> advantage, because in this way already existing clients or servers can
> be used to or tested against.

I think, support of existing protocols to connect to other clients or more 
general other apps can and should stil be delegated to plugins.
It should not be the main focus of vdr to wish to connect to other clients.

Even more - I believe, if future design of vdr is good enuf, there's no more 
need to want any other clients :)

kind regards


More information about the vdr mailing list