[linux-dvb] DVB API update
tmbinc at elitedvb.net
Wed Sep 19 00:57:31 CEST 2007
>> Why don't abstract the dvb layer from enduser applications and put a
>> general library infront which does that version check and tries to
>> keep things consistend to the end applications?
> It is a nice idea, yes.
> Two things, looking at
dvbfe_set imposes a certain programming scheme (because it sleeps). This
is a total no-go for a generic library. I don't want a library telling
me that I have to use threads (instead of poll()).
Other than that, I think it's fine, or better: it doesn't do any harm.
At the moment, I can only see that it adds another layer of indirection,
but no real gain.
Especially, such a library shouldn't be an excuse for a bad API.
And, what's the big difference between a userspace library and an API?
In what situation will the additional wrapper layer help compatibility?
If we add a feature, we have to update the library as well. If we can do
that in a backward compatible way, can't we do the same on the API?
I agree that it will help at this very moment, but as soon as
applications need to deal with different library versions, we have the
same trouble again. Or did I misunderstand something? What can a library
do what an API cannot do?
The alsa situation is a bit different - the alsa kernel api is very
low-level, and needs some bells and whistles for easier usage. DVB is,
fortunately, much easier to use. Our existing API is fine. (Agreed, if
we ever add DMA buffers, we might need some helper app.)
Where I believe that we need a userspace helper is video processing (for
handling records and proper playback using HW decoders), but for the
frontend (or demux)?
More information about the linux-dvb