[linux-dvb] [RFC] Let the future decide between the two.

[linux-dvb] [RFC] Let the future decide between the two.

[Michel Verbraak]

I have been following the story about the discussion of the future of 
the DVB API for the last two years and after seen all the discussion I 
would like to propose the following:

- Keep the two different DVB API sets next to one another. Both having a 
space on Linuxtv.org to explain their knowledge and how to use them.
- Each with their own respective maintainers to get stuff into the 
kernel. I mean V4L had two versions.
- Let driver developers decide which API they will follow. Or even 
develop for both.
- Let application developers decide which API they will support.
- Let distribution packagers decide which API they will have activated 
by default in their distribution.
- Let the end users decide which one will be used most. (Probably they 
will decide on: Is my hardware supported or not).
- If democracy is that strong one of them will win or maybey the two 
will get merged and we, the end users, get best of both worlds.

As the subject says: This is a Request For Comment.

Regards,

Michel (end user and application developer).


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Let the future decide between the two.

[Christophe Thommeret]

Le Thursday 25 September 2008 08:45:28 Michel Verbraak, vous avez écrit :
> I have been following the story about the discussion of the future of
> the DVB API for the last two years and after seen all the discussion I
> would like to propose the following:
>
> - Keep the two different DVB API sets next to one another. Both having a
> space on Linuxtv.org to explain their knowledge and how to use them.
> - Each with their own respective maintainers to get stuff into the
> kernel. I mean V4L had two versions.
> - Let driver developers decide which API they will follow. Or even
> develop for both.
> - Let application developers decide which API they will support.
> - Let distribution packagers decide which API they will have activated
> by default in their distribution.
> - Let the end users decide which one will be used most. (Probably they
> will decide on: Is my hardware supported or not).
> - If democracy is that strong one of them will win or maybey the two
> will get merged and we, the end users, get best of both worlds.
>
> As the subject says: This is a Request For Comment.
>
> Regards,
>
> Michel (end user and application developer).

2 years ago, i would have said "good idea".
But 2 years ago.

-- 
Christophe Thommeret


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Let the future decide between the two.

[Markus Rechberger]

On Thu, Sep 25, 2008 at 8:59 AM, Christophe Thommeret <hftom@free.fr> wrote:
> Le Thursday 25 September 2008 08:45:28 Michel Verbraak, vous avez écrit :
>> I have been following the story about the discussion of the future of
>> the DVB API for the last two years and after seen all the discussion I
>> would like to propose the following:
>>
>> - Keep the two different DVB API sets next to one another. Both having a
>> space on Linuxtv.org to explain their knowledge and how to use them.
>> - Each with their own respective maintainers to get stuff into the
>> kernel. I mean V4L had two versions.
>> - Let driver developers decide which API they will follow. Or even
>> develop for both.
>> - Let application developers decide which API they will support.
>> - Let distribution packagers decide which API they will have activated
>> by default in their distribution.
>> - Let the end users decide which one will be used most. (Probably they
>> will decide on: Is my hardware supported or not).
>> - If democracy is that strong one of them will win or maybey the two
>> will get merged and we, the end users, get best of both worlds.
>>
>> As the subject says: This is a Request For Comment.
>>
>> Regards,
>>
>> Michel (end user and application developer).
>
> 2 years ago, i would have said "good idea".
> But 2 years ago.
>

I agree on that, this should then also count for other things which
are going on.
Even after those 2 years it would keep the whole thing rolling when allowing
both technologies while it won't kick out anyone else.
As for the enduser it's the best way to go since all devices would be supported
with the least extra development costs now.

Markus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Let the future decide between the two.

[Janne Grunau]

On Thursday 25 September 2008 08:45:28 Michel Verbraak wrote:
> I have been following the story about the discussion of the future of
> the DVB API for the last two years and after seen all the discussion
> I would like to propose the following:
>
> - Keep the two different DVB API sets next to one another. Both
> having a space on Linuxtv.org to explain their knowledge and how to
> use them. - Each with their own respective maintainers to get stuff
> into the kernel. I mean V4L had two versions.
> - Let driver developers decide which API they will follow. Or even
> develop for both.
> - Let application developers decide which API they will support.
> - Let distribution packagers decide which API they will have
> activated by default in their distribution.
> - Let the end users decide which one will be used most. (Probably
> they will decide on: Is my hardware supported or not).
> - If democracy is that strong one of them will win or maybey the two
> will get merged and we, the end users, get best of both worlds.
>
> As the subject says: This is a Request For Comment.

This is complete nonsense, distrobution packagers shouldn't decide which 
API should be used, the API and all drivers should be in the kernel. 
Having two tree is at best fragmentation and at worst a whole lot of 
duplicated work.
That should a user do if he has two devices which are only supported by 
one of the trees? That's bad luck?
Users can't decide because they are either forced by hardware or the 
application to use a tree. The only way to avoid this duplicated work. 

This is a stupid compromise proposal appeal both parties. A decision was 
made S2API is already merged we should just with it.

Janne

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] RE : [RFC] Let the future decide between the two.

[Thierry Lelegard]

> De : linux-dvb-bounces@linuxtv.org 
> [mailto:linux-dvb-bounces@linuxtv.org] De la part de Janne Grunau
> Envoyé : jeudi 25 septembre 2008 12:48
> À : linux-dvb@linuxtv.org
> Objet : Re: [linux-dvb] [RFC] Let the future decide between the two.
> 
> 
> On Thursday 25 September 2008 08:45:28 Michel Verbraak wrote:
> [...]
> > I would like to propose the following:
> >
> > - Keep the two different DVB API sets next to one another. Both
> > having a space on Linuxtv.org to explain their knowledge and how to
> > use them. - Each with their own respective maintainers to get stuff
> > into the kernel. I mean V4L had two versions.
> > - Let driver developers decide which API they will follow. Or even
> > develop for both.
> > - Let application developers decide which API they will support.
> > - Let distribution packagers decide which API they will have
> > activated by default in their distribution.
> > - Let the end users decide which one will be used most. (Probably
> > they will decide on: Is my hardware supported or not).
> > - If democracy is that strong one of them will win or maybey the two
> > will get merged and we, the end users, get best of both worlds.
> >
> > As the subject says: This is a Request For Comment.
> 
> This is complete nonsense, distrobution packagers shouldn't 
> decide which 
> API should be used, the API and all drivers should be in the kernel. 
> Having two tree is at best fragmentation and at worst a whole lot of 
> duplicated work.

Having the two coexisting API is a COMPLETE SOFTWARE DESIGN NONSENSE.

This would not be a "cathedral to bazaar" transition, as someone wrote
on the subject, it would be a "bazaat to mess" transition.

I have no technical opinion on Multiproto vs. S2API since I have been
using only DVT-T device for the last two years. But I have more than
20 years of experience in software design and that would be for sure
the worst decision ever.

On a user point of view, Janne's point is the most important one:
> That should a user do if he has two devices which are only 
> supported by one of the trees? That's bad luck?

And this is not only a Multiproto vs. S2API issue. As I mentioned,
I use only DVT-T devices. I have 4 of them, all working on Linux
for months or years and there is no one single repository supporting
all of them at the same time. Most are supported by
http://linuxtv.org/hg/v4l-dvb, another one needs
http://linuxtv.org/hg/~anttip/af9015 plus other patches.
And this is not a transitional situation, it lasts for months.

This is an endemic but unacceptable situation. And, again, this is
not only Multiproto vs. S2API. IMHO, linux DVB has a real leadership
problem. There are just too many different forks which could be accepted
during transition periods (development and validation of a driver)
but which cannot survive that long.

All these various trees contains technically good code. So, this
is not a technical problem. Failing to merge them is a leadership
problem ("cathedral companies" would say a "management problem").

Imagine what would be the kernel today with that kind of methods?
But for the kernel, there is Linus, a leader that you may like or
not but that everyone respect (and respect the decisions of). The
situation in Linux DVB is not like that, unfortunately.

Since Linux DVB is a subsystem of the kernel and since there is
no undisputed leader in Linux DVB, why not asking for Linus'
arbitration? He started to get involved AFAIK.

Currently, all arguments are like:
- "This API is technically better" (not a technical problem we told you)
- "Give me technical reasons" (same)
- "This was voted" (validity of this vote is disputed -> leadership pb)
- "You don't like me" (personal problems)

One way to get out of this loop is to call for Linus.

-Thierry


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] RE : [RFC] Let the future decide between the two.

[Markus Rechberger]

On Thu, Sep 25, 2008 at 2:10 PM, Thierry Lelegard
<thierry.lelegard@tv-numeric.com> wrote:
>> De : linux-dvb-bounces@linuxtv.org
>> [mailto:linux-dvb-bounces@linuxtv.org] De la part de Janne Grunau
>> Envoyé : jeudi 25 septembre 2008 12:48
>> À : linux-dvb@linuxtv.org
>> Objet : Re: [linux-dvb] [RFC] Let the future decide between the two.
>>
>>
>> On Thursday 25 September 2008 08:45:28 Michel Verbraak wrote:
>> [...]
>> > I would like to propose the following:
>> >
>> > - Keep the two different DVB API sets next to one another. Both
>> > having a space on Linuxtv.org to explain their knowledge and how to
>> > use them. - Each with their own respective maintainers to get stuff
>> > into the kernel. I mean V4L had two versions.
>> > - Let driver developers decide which API they will follow. Or even
>> > develop for both.
>> > - Let application developers decide which API they will support.
>> > - Let distribution packagers decide which API they will have
>> > activated by default in their distribution.
>> > - Let the end users decide which one will be used most. (Probably
>> > they will decide on: Is my hardware supported or not).
>> > - If democracy is that strong one of them will win or maybey the two
>> > will get merged and we, the end users, get best of both worlds.
>> >
>> > As the subject says: This is a Request For Comment.
>>
>> This is complete nonsense, distrobution packagers shouldn't
>> decide which
>> API should be used, the API and all drivers should be in the kernel.
>> Having two tree is at best fragmentation and at worst a whole lot of
>> duplicated work.
>
> Having the two coexisting API is a COMPLETE SOFTWARE DESIGN NONSENSE.
>
> This would not be a "cathedral to bazaar" transition, as someone wrote
> on the subject, it would be a "bazaat to mess" transition.
>
> I have no technical opinion on Multiproto vs. S2API since I have been
> using only DVT-T device for the last two years. But I have more than
> 20 years of experience in software design and that would be for sure
> the worst decision ever.
>
> On a user point of view, Janne's point is the most important one:
>> That should a user do if he has two devices which are only
>> supported by one of the trees? That's bad luck?
>
> And this is not only a Multiproto vs. S2API issue. As I mentioned,
> I use only DVT-T devices. I have 4 of them, all working on Linux
> for months or years and there is no one single repository supporting
> all of them at the same time. Most are supported by
> http://linuxtv.org/hg/v4l-dvb, another one needs
> http://linuxtv.org/hg/~anttip/af9015 plus other patches.
> And this is not a transitional situation, it lasts for months.
>
> This is an endemic but unacceptable situation. And, again, this is
> not only Multiproto vs. S2API. IMHO, linux DVB has a real leadership
> problem. There are just too many different forks which could be accepted
> during transition periods (development and validation of a driver)
> but which cannot survive that long.
>
> All these various trees contains technically good code. So, this
> is not a technical problem. Failing to merge them is a leadership
> problem ("cathedral companies" would say a "management problem").
>
> Imagine what would be the kernel today with that kind of methods?
> But for the kernel, there is Linus, a leader that you may like or
> not but that everyone respect (and respect the decisions of). The
> situation in Linux DVB is not like that, unfortunately.
>
> Since Linux DVB is a subsystem of the kernel and since there is
> no undisputed leader in Linux DVB, why not asking for Linus'
> arbitration? He started to get involved AFAIK.
>

look at the wireless framework, sound framework all went through some evolution.

There are around 18 devices supported by multiproto and a few ones
supported by Stevens proposal.
Steven is pulling against the multiproto path which has been available
for years.

searching google for multiproto dvb returns >40.000 hits

for s2api dvb returns  277 hits
or "s2 api" dvb returns 288 hits

Markus

> Currently, all arguments are like:
> - "This API is technically better" (not a technical problem we told you)
> - "Give me technical reasons" (same)
> - "This was voted" (validity of this vote is disputed -> leadership pb)
> - "You don't like me" (personal problems)
>
> One way to get out of this loop is to call for Linus.
>
> -Thierry
>
>
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
>

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] RE : [RFC] Let the future decide between the two.

[Mauro Carvalho Chehab]

On Thu, 25 Sep 2008, Thierry Lelegard wrote:

> I use only DVT-T devices. I have 4 of them, all working on Linux
> for months or years and there is no one single repository supporting
> all of them at the same time. Most are supported by
> http://linuxtv.org/hg/v4l-dvb, another one needs
> http://linuxtv.org/hg/~anttip/af9015 plus other patches.
> And this is not a transitional situation, it lasts for months.

Patches are merged upstream when their authors think they're ready and 
sends a pull request.

In the case of af9015, Antti sent us a pull request those days and were 
merged this week at the development tree. It should be available for 
2.6.28.

Cheers,
Mauro

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[linux-dvb] RE : RE : [RFC] Let the future decide between the two.

[Thierry Lelegard]

> De : Mauro Carvalho Chehab [mailto:mchehab@infradead.org] 
> Envoyé : jeudi 25 septembre 2008 14:46
> 
> On Thu, 25 Sep 2008, Thierry Lelegard wrote:
> 
> > I use only DVT-T devices. I have 4 of them, all working on Linux
> > for months or years and there is no one single repository supporting
> > all of them at the same time. Most are supported by
> > http://linuxtv.org/hg/v4l-dvb, another one needs
> > http://linuxtv.org/hg/~anttip/af9015 plus other patches.
> > And this is not a transitional situation, it lasts for months.
> 
> Patches are merged upstream when their authors think they're 
> ready and 
> sends a pull request.
> 
> In the case of af9015, Antti sent us a pull request those 
> days and were 
> merged this week at the development tree. It should be available for 
> 2.6.28.

Thank you for the update. This is good news indeed.

However, this was only an example to illustrate the main point:
the leadership problem in linux dvb.

The fact that, after years of parallel and uncoordinated development,
everyone (Manu, now Antti) suddenly feel the urgent need to merge
everything is another illustration of this lack of leadership.
"Bazaar" development has never been a synonym for "uncoordinated"
development. Call it leadership or "coordinatorship", we just need it.

-Thierry


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] RE : RE : [RFC] Let the future decide between the two.

[Markus Rechberger]

On Thu, Sep 25, 2008 at 3:55 PM, Thierry Lelegard
<thierry.lelegard@tv-numeric.com> wrote:
>> De : Mauro Carvalho Chehab [mailto:mchehab@infradead.org]
>> Envoyé : jeudi 25 septembre 2008 14:46
>>
>> On Thu, 25 Sep 2008, Thierry Lelegard wrote:
>>
>> > I use only DVT-T devices. I have 4 of them, all working on Linux
>> > for months or years and there is no one single repository supporting
>> > all of them at the same time. Most are supported by
>> > http://linuxtv.org/hg/v4l-dvb, another one needs
>> > http://linuxtv.org/hg/~anttip/af9015 plus other patches.
>> > And this is not a transitional situation, it lasts for months.
>>
>> Patches are merged upstream when their authors think they're
>> ready and
>> sends a pull request.
>>
>> In the case of af9015, Antti sent us a pull request those
>> days and were
>> merged this week at the development tree. It should be available for
>> 2.6.28.
>
> Thank you for the update. This is good news indeed.
>
> However, this was only an example to illustrate the main point:
> the leadership problem in linux dvb.
>
> The fact that, after years of parallel and uncoordinated development,
> everyone (Manu, now Antti) suddenly feel the urgent need to merge
> everything is another illustration of this lack of leadership.
> "Bazaar" development has never been a synonym for "uncoordinated"
> development. Call it leadership or "coordinatorship", we just need it.
>

Thierry, I think uncoordinated development is more or less a side effect
and will happen from time to time (this has nothing to do with
maintainership as far
as I would say).
I think something like that will solve itself automatically when the
code is mature enough
of the parties.
Let the people do their own job wherever they want, the final enduser
has the advantage
of a higher quality of the driver in the end (see the broken intel
driver and the discussion
about a staging directory on the lkml just in order to avoid to break
hardware in future).

btw. this thread got again hijacked from the initial wanted discussion
of Michel.
"Let the future decide between the two."

Markus

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] RE : [RFC] Let the future decide between the two.

[P. van Gaans]

On 09/25/2008 02:10 PM, Thierry Lelegard wrote:
>> De : linux-dvb-bounces@linuxtv.org 
>> [mailto:linux-dvb-bounces@linuxtv.org] De la part de Janne Grunau
>> Envoyé : jeudi 25 septembre 2008 12:48
>> À : linux-dvb@linuxtv.org
>> Objet : Re: [linux-dvb] [RFC] Let the future decide between the two.
>>
>>
>> On Thursday 25 September 2008 08:45:28 Michel Verbraak wrote:
>> [...]
>>> I would like to propose the following:
>>>
>>> - Keep the two different DVB API sets next to one another. Both
>>> having a space on Linuxtv.org to explain their knowledge and how to
>>> use them. - Each with their own respective maintainers to get stuff
>>> into the kernel. I mean V4L had two versions.
>>> - Let driver developers decide which API they will follow. Or even
>>> develop for both.
>>> - Let application developers decide which API they will support.
>>> - Let distribution packagers decide which API they will have
>>> activated by default in their distribution.
>>> - Let the end users decide which one will be used most. (Probably
>>> they will decide on: Is my hardware supported or not).
>>> - If democracy is that strong one of them will win or maybey the two
>>> will get merged and we, the end users, get best of both worlds.
>>>
>>> As the subject says: This is a Request For Comment.
>> This is complete nonsense, distrobution packagers shouldn't 
>> decide which 
>> API should be used, the API and all drivers should be in the kernel. 
>> Having two tree is at best fragmentation and at worst a whole lot of 
>> duplicated work.
> 
> Having the two coexisting API is a COMPLETE SOFTWARE DESIGN NONSENSE.
> 
> This would not be a "cathedral to bazaar" transition, as someone wrote
> on the subject, it would be a "bazaat to mess" transition.
> 
> I have no technical opinion on Multiproto vs. S2API since I have been
> using only DVT-T device for the last two years. But I have more than
> 20 years of experience in software design and that would be for sure
> the worst decision ever.
> 
> On a user point of view, Janne's point is the most important one:
>> That should a user do if he has two devices which are only 
>> supported by one of the trees? That's bad luck?
> 
> And this is not only a Multiproto vs. S2API issue. As I mentioned,
> I use only DVT-T devices. I have 4 of them, all working on Linux
> for months or years and there is no one single repository supporting
> all of them at the same time. Most are supported by
> http://linuxtv.org/hg/v4l-dvb, another one needs
> http://linuxtv.org/hg/~anttip/af9015 plus other patches.
> And this is not a transitional situation, it lasts for months.
> 
> This is an endemic but unacceptable situation. And, again, this is
> not only Multiproto vs. S2API. IMHO, linux DVB has a real leadership
> problem. There are just too many different forks which could be accepted
> during transition periods (development and validation of a driver)
> but which cannot survive that long.
> 
> All these various trees contains technically good code. So, this
> is not a technical problem. Failing to merge them is a leadership
> problem ("cathedral companies" would say a "management problem").
> 
> Imagine what would be the kernel today with that kind of methods?
> But for the kernel, there is Linus, a leader that you may like or
> not but that everyone respect (and respect the decisions of). The
> situation in Linux DVB is not like that, unfortunately.
> 
> Since Linux DVB is a subsystem of the kernel and since there is
> no undisputed leader in Linux DVB, why not asking for Linus'
> arbitration? He started to get involved AFAIK.
> 
> Currently, all arguments are like:
> - "This API is technically better" (not a technical problem we told you)
> - "Give me technical reasons" (same)
> - "This was voted" (validity of this vote is disputed -> leadership pb)
> - "You don't like me" (personal problems)
> 
> One way to get out of this loop is to call for Linus.
> 
> -Thierry
> 
> 
> _______________________________________________
> linux-dvb mailing list
> linux-dvb@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
> 

You know, I've been thinking about setting up a new project. It's not 
going to happen because I'm not a programmer and it would get very 
messy, but my idea was to fork v4l-dvb and make it support as much as 
possible. The AF9015, TT S2-3200, TT S2-3600. There is code but all in 
seperate repositories and patches. And those three are not all (AF9015 
is apparently now merged).

I still can't help thinking that if I wouldn't have asked why the AF9005 
driver a while ago wasn't in hg yet it STILL wouldn't be in hg.

At the dev front, there should be some people with the desire to support 
as many devices as possible (should already be the case), actively 
asking driver developers how the're doing and if their code is ready to 
be merged (or maybe a seperate team is required for such a thing?). And 
possibly help if required. And if there is a driver that's working fine 
_but_ it needs some code cleanup or something else minor like that, it's 
NOT a reason to not include it at all!

I think there are even several driver developers who don't know they 
have to send a pull request but assume this happens automagically when 
it's known on the list that there is a working driver.

I just don't understand what the problem is. Is money required to buy 
the devices to test them properly? Should a team be set up to 
communicate with driver developers? Those shouldn't be unsolveable problems.

And what has happened with Multiproto/S2API.. I hardly understand. Maybe 
we should have asked for Linus a long time ago. Have him take a look at 
everything, let him make a decision and continue his chosen path. Maybe 
not as democratic but it would be a whole lot faster, I think.

P. van Gaans

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] RE : [RFC] Let the future decide between the two.

[Luca Olivetti]

En/na P. van Gaans ha escrit:

> 
> I still can't help thinking that if I wouldn't have asked why the AF9005 
> driver a while ago wasn't in hg yet it STILL wouldn't be in hg.
[.....]
> I think there are even several driver developers who don't know they 
> have to send a pull request but assume this happens automagically when 
> it's known on the list that there is a working driver.

That was the case for the af9005: I didn't know how to properly do it 
(in part because many of my queries went unanswered).

Bye
-- 
Luca


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Let the future decide between the two.

[Andy Walls]

On Thu, 2008-09-25 at 08:45 +0200, Michel Verbraak wrote:
> I have been following the story about the discussion of the future of 
> the DVB API for the last two years and after seen all the discussion I 
> would like to propose the following:
> 
> - Keep the two different DVB API sets next to one another. Both having a 
> space on Linuxtv.org to explain their knowledge and how to use them.
> - Each with their own respective maintainers to get stuff into the 
> kernel. I mean V4L had two versions.
> - Let driver developers decide which API they will follow. Or even 
> develop for both.
> - Let application developers decide which API they will support.
> - Let distribution packagers decide which API they will have activated 
> by default in their distribution.
> - Let the end users decide which one will be used most. (Probably they 
> will decide on: Is my hardware supported or not).

Having two API's is a software maintenance burden both for kernel
developers and application dev's that want their stuff to "just work"
for the end user in all situations.

The purpose of an API is to insulate apps developers from kernel
changes.  What you propose is, I would think, the worst case scenario
for an application developer: an API that can change completely out from
under them at any time (e.g. at the choice of a distribution packager).

If you really want that sort of choice for application developers, you
would build a library that is a thunking layer to present a different
API to the app than the in kernel API.  (I am not a serious application
developer, but for what it's worth, I don't think I would bother with
that unless I had a large complex app already written.)

Regards,
Andy

> - If democracy is that strong one of them will win or maybey the two 
> will get merged and we, the end users, get best of both worlds.


> As the subject says: This is a Request For Comment.
> 
> Regards,
> 
> Michel (end user and application developer).



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] [RFC] Let the future decide between the two.

[Michel Verbraak]

Andy Walls schreef:
> On Thu, 2008-09-25 at 08:45 +0200, Michel Verbraak wrote:
>   
>> I have been following the story about the discussion of the future of 
>> the DVB API for the last two years and after seen all the discussion I 
>> would like to propose the following:
>>
>> - Keep the two different DVB API sets next to one another. Both having a 
>> space on Linuxtv.org to explain their knowledge and how to use them.
>> - Each with their own respective maintainers to get stuff into the 
>> kernel. I mean V4L had two versions.
>> - Let driver developers decide which API they will follow. Or even 
>> develop for both.
>> - Let application developers decide which API they will support.
>> - Let distribution packagers decide which API they will have activated 
>> by default in their distribution.
>> - Let the end users decide which one will be used most. (Probably they 
>> will decide on: Is my hardware supported or not).
>>     
>
> Having two API's is a software maintenance burden both for kernel
> developers and application dev's that want their stuff to "just work"
> for the end user in all situations.
>
> The purpose of an API is to insulate apps developers from kernel
> changes.  What you propose is, I would think, the worst case scenario
> for an application developer: an API that can change completely out from
> under them at any time (e.g. at the choice of a distribution packager).
>
> If you really want that sort of choice for application developers, you
> would build a library that is a thunking layer to present a different
> API to the app than the in kernel API.  (I am not a serious application
> developer, but for what it's worth, I don't think I would bother with
> that unless I had a large complex app already written.)
>
> Regards,
> Andy
>
>   
Andy,

I agree that the best solution is to have one working API (Application 
Programming interface). But as we live in a complex world  we see the 
same social events happening on the Linux DVB ML as in the real world 
where we have two groups who think and say their solution is the best 
and none is willing to cooperate with one another. We see a fight about 
which group is the strongest measured by send in patches or who is able 
to attend a single meeting.

The main thing is that we have hardware developers who, I think, would 
like their hardware being used by end users.  They spend time in 
developing their hardware but do not sponsor developers to get the 
hardware working in non Windows environments. The reason for this is 
simple Windows is used most and more profitable. What I hear on this ML 
is that the linux DVB developers do it in their free time and this, I 
think, is not completely true. I think that for most of the current 
developers that also respond on this mailing list there is a commercial 
benefit in it to them or some company and we the end users must be happy 
with whatever they produce or not produce.

What I would like to know from the current Linux DVB driver developers 
is who is working for which company and gets paid for his work. If their 
employers/contracters would like to have one common API they would 
arrange that the developers could meet more.

With DVB on linux we have different groups with different solutions for 
different hardware but each hardware group has a (partial) working 
solution. I as an end user will choose one of the hardware groups based 
on price and user experience and follow the solution for this group.

I as an end user will make the descision on what I think is best for me.

Regards,

Michel.

>> - If democracy is that strong one of them will win or maybey the two 
>> will get merged and we, the end users, get best of both worlds.
>>     
>
>
>   
>> As the subject says: This is a Request For Comment.
>>
>> Regards,
>>
>> Michel (end user and application developer).
>>     
>
>
>   



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb