On Tue, May 23, 2006, Julian Scheel wrote: > after going through most of this discussion now I finally decided to > join it at this point. > First of all I'd like to address Johannes complaints about only Manu > participating at this discussion. I actually stayed in the background > until now, because my knowledge of the linuxtv-development of the past > is pretty vague, as I actually joined this whole thing not too long ago. > Actually I thought (and still think) Manu would do a better job > explaining the API, than I could do. Currently my problem is that I still don't understand some parts of DVB-S2, and so have difficulties to decide what the requirements for the API are, if the API proposal meets the requirements, and if the chosen solution is the best I can think of. So currently there is pretty little Linux specific in this discussion, it addresses the same problems you'd face if you were to write your own proprietary API. [snipped S2 usage overview] -- Thanks! > Actually an even more interesting point are the concerns of Johannes of > adding too many details to the API. Actually my impression is that, as > said by others too, in the past every possible detail went into the API, > why should this be wrong now? It isn't wrong in itself, I'm sorry if I made that impression. But you know, in every proposal I've seen so far struct dvbs2_params changed a bit -- parameters were added, removed or changed. And I repeatedly asked for an explanation how the API works, i.e. how it would be used in practice by an application developer. Which parameters are necessary for tuning, and where do you get the values from? Which are only for querying some detail info for curious people? Which are for receiving simple HDTV and which are for some exotic DSNG or IP-via-DVB ACM stuff? As a consequence of the debate I decided it's best to dumb it down for now, and just implement the basic stuff needed now for receiving the existing DVB-S2 broadcasts. And surprise -- we can't even seem to agree what's necessary here :-( > I can basically follow your concerns of having to remove parts of the > API later, but in this case we don't talk about "wrong" additions, but > about additions that might not be used in the end, because no > broadcaster uses them. Actually this wouldn't be a problem, as it only > would make sure that we would be aware of all possibilities and wouldn't > come into a situation where someone starts using a part of the spec > which we previously declared as not important. In the worst case it > could become a big problem adding those parts later on, because they > would break binary compatibility in a non-EXPERIMENTAL state. My impression is that all DVB-S2 proposals so far were immature and haven't even reached EXPERIMENTAL stage. (Where EXPERIMENTAL means: Not 100% ready, but good enough to include in mainline kernels and let people interested in the subject play with it. IOW it must *work*, and it must be documented or obvious *how* it works.) Look at it this way: If *I* don't understand the API, how can you expect someone like Klaus Schmidinger implement support for it in VDR? - how to do service scan for DVB-S2 - what changes are necessary for channels.conf - which new ioctsl, and how to use them - how to maintain backwards compat with old kernels Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
