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