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

["Rene Bartsch" <ml@bartschnet.de>]

----- Original Message -----
From: "Reinhard Walter Buchner" <rw.buchner@freenet.de>
To: <vdr@linuxtv.org>
Sent: Wednesday, March 26, 2003 3:46 PM
Subject: [vdr] Re: Idea how to generate a OSD-Main-Menu from a plugin



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

You got it.

>
> 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

It will need a lot of work. But as we get a lot of feature-requests on the
list, this would be a flexible way to fullfill all user's needs.
At the beginning it's heavy, but on long shot it will save work and make VDR
a powerful Multimedia-system/server.
With the current way, we'll have the risk of breaking something every new
1.x version.

>
> - 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"

Klaus does great work and we can't expect him to maintain everything for
everyone, of course.
But this also limits VDR to Klaus' needs.

So we'd need a workgroup which defines the core-skeleton and plugins are
implemented by volunteers, like done for the current versions.
Klaus could do the major releases - like a stability certified core-VDR with
the most common plugins.

>
> - 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.

And there isn't much they can really do (e.g. a SVDRP-plugin for Timers).

> 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.

So we need a well defined skeleton and some quality-management. This can be
done by the workgroup and Klaus. When a plugin arrives, it is defined
"unstable". when it works without breaking things it will be defined
"testing". When all errors are debugged it will be defined stable and Klaus
puts it into his release.

This way Debian is very successful only by volunteers and look what nice
package-management they have.

>
> 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.

But histrically grown code has the problem that bugs exponentiate with every
releasy.

So mathematical/logical checking should be done.

>
> 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.

Yes, but Klaus isn't God. I think there are often days where he'd like to
answer mails with "Hey, stop floating me with silly questions, I want a free
day!"
Everyone expects Klaus to solve his personal VDR-problems.


>
> > 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.

I'm dreaming of a homepage, where you select which functions you want and
press download button.
Then you get a nice tar-file with VDR-skeleton and the necessary plugins, do
a "tar -xjf VDR-x..y.z.tar.bz2" and a make.

And then VDR is ready to run. This will increase amount of users rapidly.

And Debian is the best proof it works, if the developers work hand in hand
and you have a  well specified base.

And yes, my parents are 60 and 50, my father works with computers for ten
years, now. He still hasn't realized what a window or a directory is and
drives me crazy, whenever I'm at my parents - or he calls something is
broken again.

>
> 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.

See Debian.

>
> > 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.

Remux.c would need some PTS-/package-size-functions, etc.
The simpler way would be to implement a transcode interface into remux.c and
use the transcode plugin.

Additionally the functions for indexing would have to be adapted to use
internal time-stamps instead of index.vdr - or both.

>
> > 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.

I was referring to Sascha Volkenandt's questions how to transfer timers from
a VDR-client to a VDR-server.

>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.

And all expectations are on Klaus, again. VDR is his hobby, but everyone
expects him to be available 48 hours a day.

> 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.
>

This for we human beings have had a little evolution of brain. If everything
is organized well by clear but flexible specifications, there won't be much
overhead.

Renne




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