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 , Tvheadend , …) 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
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 :)
vdr mailing list