Steve,<br>Does this mean you will be working on an alternative to MultiProto? <br>As an HVR4000 user I am following this thread closely as you might imagine.<br><br>Ian<br><br><br><div><span class="gmail_quote">On 11/1/07,
<b class="gmail_sendername">Steven Toth</b> <<a href="mailto:stoth@linuxtv.org">stoth@linuxtv.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Manu Abraham wrote:<br>> Steven Toth wrote:<br>>> Johannes Stezenbach wrote:<br>>>> Hi,<br>>>><br>>>> On Tue, Oct 30, 2007, Manu Abraham wrote:<br>>>><br>>>>> Johannes Stezenbach wrote:
<br>>>>><br>>>>>> three weeks have passed since Steve expressed his<br>>>>>> discomfort with the HVR4000 merge being blocked<br>>>>>> waiting for multiproto.<br>>>>>>
<br>>>>> Before i state anything, Current DVB-S2 API status:<br>>>>><br>>>> [snip]<br>>>><br>>>> Thanks, that's useful.<br>>>><br>>>><br>>> Yes.
<br>>><br>>>>>> Can you give us a time frame for when the multiproto<br>>>>>> merge will happen?<br>>>>>><br>>>>>> Or, alternatively, can we split multiproto into
<br>>>>>> two repositories, one with API + dvb-core changes<br>>>>>> and one (on top of it) with the STB0899 driver?<br>>>>>><br>>>>> It can be either way, which one of the following do you think is
<br>>>>> better in your view ?<br>>>>><br>>>>> (1) DVB-S2 API partly merged now and the rest of the S2 API later.<br>>>>> (2) Complete event list update and VCM and merge that also alongwith.
<br>>>>><br>>>>> in either case it can be with or without the STB0899 driver.<br>>>>><br>>>>> What do you think ?<br>>>>><br>>>> I'd prefer to address the remaining API issues first, however
<br>>>> what I primarily want to avoid is that Steve rewrites the<br>>>> HVR4000 driver to a competing API proposal due to<br>>>> frustration with the lack of progress.<br>>>><br>>>>
<br>>> Agreed.<br>>><br>>>> IMHO there should be a clear path of actions for Steve<br>>>> (or whoever else wants to help) to do that would allow merging<br>>>> the HVR4000 driver. I.e
. instead of having to wait for some<br>>>> event beyond his control there should be a checklist, and<br>>>> the merge can happen when all items are resolved.<br>>>><br>>>> Or something like that. Preferably Steve would comment
<br>>>> how he'd like to go forward.<br>>>><br>>>><br>>> If these are new API's then I suspect the HVR4000 doesn't use them. I<br>>> would agree it makes sense to define them, but depending on their focus
<br>>> they may not need to be implemented and should not be considered a<br>>> roadblock to an alpha release.<br>>><br>>> If they don't impact core functionality then I see no reason why this<br>
>> cannot be defined now, but implement (and refined) later during the test<br>>> cycle. (I'm expecting testing to be a very long process, because we'll<br>>> need to encourage the VDR/MythTV/Other applications groups to begin
<br>>> integration).<br>>><br>>> I am a realist. I don't expect the first tree will be perfect. I am<br>>> expecting some change. I am expecting apps devs/testers to find bugs and<br>>> problems which will cause us to rethink some parts of the multiproto
<br>>> core and it's S2 drivers.<br>>><br>>> No doubt the VDR and MythTV folks will also have something to say and<br>>> that may impact the API also. We need to pay respect to the opinions of<br>
>> the applications developers.<br>>><br>>> I don't think the first release needs to be perfect.<br>>><br>>> I think if the current API is good enough to support the needs of<br>>> Myth/VDR then that's something we can start with. Release early, release
<br>>> often.<br>><br>><br>> It is not how the APi is good enough to support the needs of MythTV or VDR,<br>> but how the API can be considered as a guide for the application developers<br>> to understand how to talk to a DVB-S2 device
<br>><br>><br>>> Manu, this is your patch and I respect your work, how would you suggest<br>>> we proceed?<br>>><br>><br>> There does exist a ported version of VDR to the new API. The current situation
<br>> is that the S2 devices cannot be tuned to certain frequencies because of the<br>> use of Backward compatible modes, ie the API, nor the drivers currently do<br>> support them.<br>><br>> Give application developers a chance to mess up stating that the API is out,
<br>> eventually what will happen is: example look at people crying out on<br>> mythtv issues with regards to DVB devices. I have had quite some experiences<br>> trying to make application developers understand what they do wrong.
<br>><br>> I am waiting to hear from other developers as well, whether they would like to<br>> do whether to do<br>><br>> (1) partial DVB-S2 API support now and the rest of the DVB-S2 API later.<br>> (2) DVB-S2 API what it needs to tune to all the transponders at least
<br>><br>> Look, this is not the question of the HVR4000 or the STB0899 alone, it will affect<br>> all future devices. As Johannes said, what goes into the API (user ABI) is permanent,<br>> it won't change. It is something that will be set in stone as opposed to the driver
<br>> internal API. (The driver API we can change, but not the ABI) What we are looking at<br>> is the API-ABI<br>><br>> Let me cite certain examples of such large scale screwups where people are stuck:<br>>
<br>><br><br>You've miss-interpreted my comments.<br><br>I suggested that the API should be defined, but not necessarily<br>implemented. I was suggesting that we define enough API to generate a<br>test tree and make some progress. Supporting your earlier statement, I
<br>suggested that the small amount of unimplemented API (which you<br>suggested was inconsequential) could be implemented while other<br>developers were testing the core TV functionality.<br><br>I.e. This becomes a group effort, not a Manu effort.
<br><br>I never suggested the test tree would get merged, in fact I went out of<br>my way to suggest that the process of testing would likely raise various<br>design issues and/or bugs. I clearly outlined that I'm a realist and I
<br>expected this testing phase to cause change.<br><br>I thought I'd made myself clear.<br><br>I ended my previous email respectfully and repeated Linus's mantra. I<br>was assuming your response would be positive.
<br><br>Instead you've launched into a patronizing tirade and none of this<br>ingratiates you with the other developers, it only stands in the way of<br>progress and demonstrates the attitude we've witnessed over the last
<br>12-18 months re: multiproto.<br><br>I don't think I have anything else to say on the subject of multiproto,<br>until you see fit to deliver publically your 'marvelous multiproto<br>invention - all things under one roof', no doubt to the sound of
<br>trumpets, gasps and country wide applause.<br><br>I'm wasting my time here.<br><br>- Steve<br><br><br><br><br>_______________________________________________<br>linux-dvb mailing list<br><a href="mailto:linux-dvb@linuxtv.org">
linux-dvb@linuxtv.org</a><br><a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb">http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb</a><br></blockquote></div><br>