[vdr] Re: where is vdr goin' to?

[Rene Bartsch <ml@bartschnet.de>]

Sascha Volkenandt schrieb:

> Most of that dependencies are (apart from DVB) created by PlugIns, not by 
> VDR itself, or am I wrong?
Of course, but what I mean is e.g. to use another DVB-driver which could 
easily be done when the DVB-driver is moved into a plugin. The headers 
and includes necessary to access DVB-API should be in the VDR-code or in 
a DVB-plugin. So any DVB-modules included in the kernel or stand alone 
by any vendor could be used by just having the same interface - DVB-API 
- but not sharing code.

I don't like to be limited to one unreliable part of software like the 
current DVB-driver. That's why I have moved off M$ after using it for 
nine years and decided for Linux and OpenSource two years ago.

But what drives me crazy in linux are the dependencies. For compiling 
you need the headers and includes, which often differ from one 
sub-version of a program/library to another. If you have one program 
demanding a new version and one program demanding a old version you're 
in trouble as you often can't install them in parallel.

That's why I'm praying for complete software-modules with well-defined 
interfaces. Just copy the necessary code of DVB-driver into VDR and 
provide VDR with that code.

I like VDR very much and Klaus has done great work!

But it's a hobby for him and his needs. But our needs may differ from 
user to user, so a roadmap would be fine to see if VDR will fullfill the 
needs.

I don't want Klaus to fix milestones on time-lines, but a nice ToDo and 
what he wants to do. This would also allow others to provide parts of 
code for VDR -> teamwork.

Additionally we had the problem VDR-1.0.4 had to be thrashed and 
completely rewritten as it was to static - and it seems we have the same 
problem for approaching 1.3. In turn, this means a lot of superfluos 
work to rewrite the core every time which is a drawback of every project 
of historical growth.

So my suggestion @Klaus:

Let's do some brainstorming which functions are needed for VDR.
Then we can sit down and do some software-engineering for a VDR-core 
which consists of encapsulated modules with open interfaces to be easily 
extendend with I/O-plugins.

This will of course be some awful month of discussing dry flowcharts and 
 well-defined interfaces, but then you can distribute 
programmings-tasks on the list and we'll have a reliable and extendable 
VDR-core within the next time.

Rene



--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.