[vdr] Re: VDR is obsolete, not really of course

[Benjamin Forgeau <forgeau@tu-harburg.de>]

	Hi,

> > the pros and cons of the internal structure of linux:
> >         http://www.oreilly.com/catalog/opensources/book/appa.html
> 
> And we all know how it ended: Linux is still there!

	Sure! Of course I never meant the end of VDR, by the way, even if the 
subject sounds like this. My apologize again for the silly subject. I 
did not even mean any change in the code of VDR or about its handling 
of the hardware, just some changes in the code organization.

[snip]

> These things already work pretty good in VDR, so why should I break a 
well
> working program into pieces, risking that it won't work that well any 
more?

	Because it handicaps further DVB development! It is a kind of 
monopoly! Ok ok, these words are too strong, but this is the situation. 
Let's say I would like to create a small project that use the pieces. I 
don't want to rewrite everything. I don't want to make unmaintainable 
patches or forks into VDR. Then I will use a library, or start one 
myself. VDR will continue to be a killer-app, a kind of  bulldozer in 
the DVB microcosm, it means that all the innovations will be first 
implemented in VDR. If I want the new things, I will have to 
re-implement them in my library. And for ever the same problems..

	Another simple thing: I have a DVB-C card at home, and I need a tuning 
sub-program. I will re-write a tuning sub-program that works for me, 
and my program won't be able to work with a DVB-S. With a library it 
would be no problem, I would use a "tune this channel" function.

	I can really understand if you are angry about my messages: I'm just 
this kind of jocker coming from nowhere and saying that everything is 
wrong. No, I never implemented something using a DVB-Card, and I 
want to know it better than everybody!

	Don't get me wrong, I don't like to write troll-mails, I'm just 
frustrated, VDR is a beautiful app, and I can't really use the code as 
I want in a clean way. I'm feeling the development could go in a 
smarter direction, I think it is high time to think deeper about it.

	Then some pros and cons:

	PROS
	
	* Ben and perhaps some other developers can benefit from the core code 
of VDR without trying to create horrible patches or forks, they must be 
sure that a plugin could not be an adequate solution.

	* Bugs in the core library could be fixed by others and then 
automatically be fixed in VDR.

	* Many other programs can use the core functions of VDR in many 
situations, bugs can be detected faster.

	* There is a clear separation between the interface, the core 
functions and the plugins system.


	CONS

	* It is a big risk for the stability to break VDR in independent 
pieces, and a lot of re-organization work.

	* libdvbsak is C-based, like an core library should be (well.. 
imho..), VDR is C++-based.

	* VDR will rely on code that can be modified by any unexperienced 
hacker that will implement buggy functions.




	Well.. this list is not exhaustive now.

	However, I would bet that re-organizing the code would be nothing in 
comparison with the addition of the plugin system in VDR.

	The idea of a DVB lib is not new: libDTV and libdvb are not really 
highly maintained as far as I know, the question is why?? My answer is 
that VDR leads the development in the DVB field, leaving no other 
option.

	Klaus, you are the creator and maintainer of VDR, it is your own 
decision. It would bring almost nothing new but a lot of work for VDR, 
but imo it would be great for the other developers around. That's it.


		Kind regards 


			ben




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