[vdr] Re: Idea how to generate a OSD-Main-Menu from a plugin

["Reinhard Walter Buchner" <rw.buchner@freenet.de>]

Hi Rene, all,

>> Why would you want to outsource them into a plugin?
> > Personally, I don't think it's a good idea to start taking VDR
> > "apart" (make it modular?)

> I think modularity makes things easier.

I'm not sure about that. It *will* give the user more options
to play with, but I think it would be much harder to maintain.

What (I think) you want is VDR to become a small control
skeleton and all the rest should become plugins.

Doing so, I think there are three risky things involved:

- VDR would need a complete rewrite. Doing so,  also ups
   the chances of breaking something that already works

- Who would maintain what? Right now we have Klaus, who
   maintains the complete "system" from ground up. For example
   if he doesn't use Divx as a  recording format, we an hardly
   expect him to write and maintain a Divx recording "plugin"

- By giving the user access to *all* of VDRs internals, will
   lead to many complications and maybe even incompatibilities
   between different plugins. The way plugins have access to VDR
   right now prevents this from happening. There isn't that much
   that they can screw up. This is proven by the fact that most
   plugins run great. I have about 90% (rough guess) of the available
   plugins installed and have no problems. Okay, with some plugins
   there are minor glitches and a few pitfalls (like which version of
   lib xyz is needed), but other than that, I can't say a plugin has ever
   "broken" VDR. The more access you give and the more plugin
   "dependant" VDR gets, the higher the risk of something going
   wrong.

Of course, neither way will stop modders ;o)) You probably
assumed I would be on your "side" ;o)) Actually I am, in a way,
but I also see the hard work put into VDR and the complexity
of it all. Look how long it is taking me to release my mod. Of
course, I am NOT a prof programmer. I started out with Linux
and C in July 2002. Every mod I add, I try to test rigorously and
play DAU to find errors and hitches, where something could go
wrong (and my code is 99,99% most likely not completely
bug free) I realize that if all coders would do super intensive
error checking (*NO* offense meant at all), VDR would most
likely not be where it is now, simply because this would slow
"production" *way* down.

However, if you start to split up things, you will have a hard time
tracking down errors, simply because you have many more
dependancies. Right now we can say "Hey Klaus", I am running a
virgin VDR 1.1.xyz and I have this and this problem. Since Klaus
maintains the whole virgin VDR, he is most likely to come up
with a competent answer and solution. Imagine what would happen
if Klaus maintins the skeleton, Programmer 1 maintains the
recording part, Programmer 2 maintains the EPG data handling
Programmer 3 maintains the Timer handling. With just these
four people you already have 16(!) combinations  (assuming two
versions from each guy and that I didn't screw up my calculation)
which could lead to many problems. Klaus would have to say,
"sorry I have no idea".  This would mean we give up stability
for feature issuses.

> So you can  build your own VDR with "Bauklötzchen". (Did I play
> too much Lego Technik when I was a little boy? ;o))

I also think this would affect the amount of users willing to switch
to and use the new version. Just look at how many people are still
using 1.0.4. For many (I think) this has nothing to do with stability
or missing feature issuses, but rather the fear of something new and
totally different from what they are used to using. If you start
splitting VDR up further, you simply also risk losing users (not that
I think VDR will "die" because of this). Right now people can
download VDR and the DVB driver and with a little bit of work and
patience they have a running digital videorecorder system which
has a lot to offer. Even older people (non computer experienced)
are using VDR (I have noticed that you mention your parents quite
often ;o)) Making VDR a "Baukasten Prinzip" will scare these people,
simply because they are afraid of breaking something. I know this
from personal experience with my mom. She is 75 and started out
with her own computer about 8 years ago. In some situations she is
still afraid to break something. And yes, I can thoroughly understand
this.

Making something modular is a great idea and one thing. Making
something modular work for *everyone* is another and requires
*a LOT* more work and time.

> If someone wants another recording-format, he could just patch
> the original plugin and provide it with another name.

I assume you mean (e.g.) Divx vs VDR format? If you mean true
mpg (i.e. DVD-R ready e.g.) vs VDR's PES format, that would
become a nightmare, as there would need to be a lot of changes
in more than one area.

> Or you could just exchange the timer-plugin with a SVDRP-plugin.

Could you explain this? VDRAdmin accesses the timers via
SVDRP. "I" for example use both. I program the timers via VDR and
via vdradmin. So in my case both plugins must be able to work
simultainiously. Right now I have this "guarantee" because Klaus
implemented the timers and the SVDRP and Thomas Koch built
his vdradmin on this (stable and maintained) basis. This simply
means the combination works, because it was designed to. You
can no longer guarantee this, if Klaus does the skeleton, another
programmer does the timers, another does the SVDRP and lastly
Thomas once agin does vdradmin. There are just too many varibles
involved then.

Greetz,
Reinhard


---
Mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.463 / Virus Database: 262 - Release Date: 17.03.2003



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