On Mon, Sep 17, 2007, Manu Abraham wrote: > > The problem is that, after making something experimental, throwing it > out to application authors stating here it is: the API update, again a > fix to the API will make anyone furious, nobody wants to keep tinkering > forever on the same thing. Exactly, that's why I blocked your initial attempt to merge the DVB-S2 API extensions. *That* it was experimental code (even completely untested). But after all the discussions, and you and Steve have written drivers which I hope prove the API as working, why do you still think it is experimental? What would it take to make it non-experimental? > I would prefer to say mark it experimental in > a tree dedicated to it, such that it is explicitly stated that it is not > a permanent solution and in the background, the fixes required for the > relevant can be done. IMHO application developers hate temporary APIs -- it means they have to rewrite their code later, and there are zero guarantees as to when you make the change to the "real" API and how big the required changes would be. > Don't you think so ? If someone asked me to keep working on with changes > every now and then i wouldn't be very happy, but if i were explicitly > told, look this is what as far what it stands as of now, it is expected > to change, for further support, that i could digest it a bit. Trying to > put myself into someone else's shoes. The magic word is "backward compatibility" -- as long as that is guaranteed, everyone _loves_ small incremental updates. They are much easier to handle than the one large mega update which changes the complete API. I really don't think there is any problem in releasing API version 3.3 with DVB-S2 support now, then 3.4 with DVB-H, then 3.5 with DVB-T2 etc. And I think it would be wrong to delay DVB-S2 support until you have all of DVB-H, DVB-T2, etc. properly hammered out. > That said there are newer devices taking advantage of the full specs. As > we have seen as soon as there are devices, there are applications as > well. Vendors don't spend their funds on something nonsense and that too > a major chunk of it. Of course there are cases, but in this case i > highly doubt your claim. I have no idea what you want to say with this. Missing context? > > IIRC my closing words in the DVB-S2 API discussion were > > along the line of "we shouldn't merge an API without users > > into mainline now, we should wait until the first driver which > > uses it is ready and merge both at the same time". > > That is because a) we generally shouldn't add APIs without > > users, b) we shouldn't add APIs which are untested and > > thus not proven to work. > > IIRC, You only wrote sometime earlier, why work on something useless > such as DVB-S2. Why a change of thought ? You remember wrong, I never said this. What I said was that _at the time_ you wanted to merge your initial API proposal, there was no DVB-S2 equipment available in stores, and also no DVB-S2 transponder in operation. So your desire to get this merged _then_ was premature. > > Ever since, everyone's just been waiting for your > > "I'm ready with my driver, please merge" mail. > > I would be going on with an experimental tree after Wednesday. > > Still some more things to be polished in that CCM only case too. See the > first few posts on this DVB API update thread, The way the current API > is, well it is as good as no statistics, but just for kids play there > are some numbers scrolling up and down, ie the statistics do not hold > any value. Displaying some random numbers is not statistics. I have no idea what CCM is. If during the implementation of your DVB-S2 driver you found that the API still needs work, then why not just fix it -- that was the whole purpose of the exercise. The statistics thing is independant of DVB-S2, again I see no reason why to make the "merge DVB-S2" task bigger by dragging this into the picture. > Had a discussion with Steven too on this, since he has a driver as well. > Why this is experimental ? I guess you get all the answers from within > this mail itself. I wish you'd just stop with all those private discussions and instead keep it on the list all the time. That way everyone would have all the relevant information, which is one of the key points of doing Open Source development: spreading not just the code but also the knowledge about the technology. mrec isn't completely wrong when he says that this list gives the appearance of a closed, elitist circle where everything interesting happens in backrooms. > Sometime back you were the person who was against merging the same, now > that you seem to suddenly pull in all that you said crap a few mails > back. Wow, what a contradiction in statements. See above. If by "crap a few mails back" you mean the private discussion about this you tried to drag me into, I'm sorry but I will block any attempts by you (and others) to discuss important technical stuff in private. I'm very passionate about this, as it is an important thing to strenghten the community. If you want answers, ask on the list. > I would like to see the other features of DVB-S2 go in as well, since What other features? > there are newer devices using those features. But for that i wouldn't > prefer to work with the V3 demuxer, but prefer to go with V4 which has > the advantages of ZeroCopy at least. Demux API changes and zero copy have nothing to do with DVB-S2. > >> What i find interesting with the V4 API > >> * A better demuxer > > > > But it's also overcomplicated and like MiHu explained not > > targeted at PCI/USB cards. IMHO It would be useful to add > > a simple version of the recording filters to the V3 demux. > > Copying around, i would like to avoid. With High bitrate streams etc, > for HD streams the PC would be already saturated, i would like to cut > down whatever unnecessary overheads that do exist. > > If you would like to fix that in V3, i would much appreciate. If you > would just like to keep talking only, maybe lets then not talk too much > about it. The recording filters are exactly the piece from V4 which has the "mmap DMA buffers" zero copy API. But to be honest, I don't think it's important on a PC which can copy > 1GByte/s in RAM. More interesting would be the ability to have multiple independant filtered TS outputs instead of just one dvr device. > >> * ARIB extensions > > > > I don't see anyone writing a driver using that, so why bother? > > > > Someone asked me over IRC a few weeks back on a demod, moreover i have a > 13 seg tuner. (You have the sources for that driver from me, currently) Last time I looked the ARIB specs were available in Japanese language only, so I assumed you wouldn't work on it. But again why delay DVB-S2 support because of this? > So when you have to spent efforts again after a while again and again, > why not do it once for all ? I don't follow your argument that we have > to have flamewars every now and then. Maybe you like them so much and > blame others for it ? Why is every technical discussion a flameware (or "unnecessary")? IMHO "do it once for all" is an illusion, it will just not work. See, after all the "unnecessary" DVB-S2 discussions, more than one year after the initial API proposal you start indicating there's still some CCM piece missing (whatever it is). Now if you get DVB-H, ARIB etc. into the picture, by which time do you thing the big mega API would be finished "once for all"? Not to mention the standards which aren't really defined yet like DVB-T2 and DVB-C2, and standards which aren't even invented yet... Version numbers and incremental updates are on the the best inventions ever -- they allow you to manage change in small, easily digestable pieces. > > (V4L2 API does the same thing) > > Don't care what V4L2 is doing, but ATM more concerned about what's going > on. You can't force what someone is doing on somebody else. Maybe it was unclear, I was referring on adding padding in API data structures to make compatible extensions possible. > > See? Keep it simple. Do just one thing at a time. > > I don't see it. I hope my explanations made it easier to see. Do you see it now? > As i said, will you take charge in fixing the demuxer > for complete S2 as well as other protocols ? > (Since you had a larger hand in the whole mess created, what i mean here > is that you maintained DVB for a long while) Nice try. :-) No I won't implement anything. I give you my advice because I think it would make your life much easier and also lead to a technically better result if you would listen. You are of course free to ignore it. (And it really just meant as advice, and not as a flame of whatever.) HTH, Johannes _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
