>> 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 > http://linuxtv.org/hg/dvb-apps/file/4bca5d49c9bd/lib/libdvbapi/dvbfe.c 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)? Felix _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
