On Mon, May 22, 2006, Manu Abraham wrote: > Johannes Stezenbach wrote: > >On Mon, May 22, 2006 at 02:14:03AM +0400, Manu Abraham wrote: > > > >>Johannes Stezenbach wrote: > >> > >>>For binary compatibility it isn't sufficient to just add new > >>>fields to struct dvbs2_params. There must also be an indicator > >>>which the kernel can use to see if struct dvb_frontend_params > >>>was prepared by old or new userspace, i.e. if the new fields > >>>are valid or contain uninitialized data. > >>> > >>Well, still i do not follow this argument. How do you expect old > >>applications that do not support DVB-S2 to work with DVB-S2. Should be > >>some sort of black magic. > >> > >>Are you saying that the DVB-S applications will make DVB-S2 devices also > >>working in the same way ? > >> > >>I really got lost, now. > > > >If I wasn't clear: I mean backwards compatibility for future > >changes of the API. Or do you expect this to be the last change? > > Well, are you proposing that we keep on discussing this for ages ? On > one hand you seem to say that you don't agree on the basic stuff and > *NACK* them down. On the other hand you talk about backwards > compatibility, which i haven't even touched. > > Seriously, I really don't follow this discussion Maybe I'm unable to express myself, or you are unable to read. Either way it seems just repeating my arguments doesn't seem to make sense. Maybe someone else could comment... Anyway, one last try. Let's go back to the very beginning: - we need to extend frontend API for DVB-S2, DVB-H etc. - we cannot do so without breaking backward compatibility because of mistakes made when defining the current API - so now that we define new API, we don't want to repeat the same mistake, but design in a way that make future extensions possible without too much pain for driver and application developers - right from the beginning my position was to do the *minimal* work necessary to support the *current* requirements -- keep it simple and stupid - and add other stuff later when the need arises - and all along you totally ignored this and instead want to cram every last detail into the API that you think *might* be necessary - wrt requirements: you need to think through how an application will work (how does dvbscan discover DVB-S2 transmission? where do the tuning parameters come from?) Remember: You cannot remove anything from the API once it is in there. But you can always add stuff later. Please ask yourself who are doing this API design for, and how people are going to benefit from your work. IMHO: - users just expect to be able to buy a DVB-S2 card and watch the services broadcast *today* via DVB-S2 - application developers want to support DVB-S2 with as little hassle as possible With the new API "as little hassle as possible" for apps already means: - testing for support for the new API - fallback to using the old API for backwards compatibility :-( IMHO it is of no use to further complicate the matter by adding lots of unnecessary stuff to the API. BTW, I don't claim to be right on my interpretation of the DVB-S2 spec, however as long as we can't agree (i.e. no one can give a good explanation why his version of the DVB-S2 API is the correct one, and *everyone* can agree on it), I think the while DVB-S2 API is useless. I also say it again: I am deeply dissatisfied that none of the people you mentioned at the bottom of http://linuxtv.org/pipermail/linux-dvb/2006-May/010076.html seem to care enough to participate in the discussion. (Not to mention that app developers also don't seem to care -- after all these are the ones who'll have to deal with the new API.) Maybe we should just put the API change off for now. :-( Johannes _______________________________________________ linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
