From: Michel Verbraak <michel@verbraak.org>
To: linux-dvb@linuxtv.org
Subject: Re: [linux-dvb] [RFC] Let the future decide between the two.
Date: Fri, 26 Sep 2008 08:44:37 +0200 [thread overview]
Message-ID: <48DC84D5.2030504@verbraak.org> (raw)
In-Reply-To: <1222389776.2762.35.camel@morgan.walls.org>
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
prev parent reply other threads:[~2008-09-26 6:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-25 6:45 [linux-dvb] [RFC] Let the future decide between the two Michel Verbraak
2008-09-25 6:59 ` Christophe Thommeret
2008-09-25 7:20 ` Markus Rechberger
2008-09-25 10:48 ` Janne Grunau
2008-09-25 12:10 ` [linux-dvb] RE : " Thierry Lelegard
2008-09-25 12:19 ` Markus Rechberger
2008-09-25 12:45 ` Mauro Carvalho Chehab
2008-09-25 13:55 ` [linux-dvb] RE : " Thierry Lelegard
2008-09-25 17:35 ` Markus Rechberger
2008-09-25 16:40 ` [linux-dvb] " P. van Gaans
2008-09-26 7:47 ` Luca Olivetti
2008-09-26 0:42 ` [linux-dvb] " Andy Walls
2008-09-26 6:44 ` Michel Verbraak [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48DC84D5.2030504@verbraak.org \
--to=michel@verbraak.org \
--cc=linux-dvb@linuxtv.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox