From: Fabien Chevalier <fabchevalier@free.fr>
To: BlueZ development <bluez-devel@lists.sourceforge.net>,
Luiz Augusto von Dentz <luiz.dentz@gmail.com>,
Johan Hedberg <johan.hedberg@nokia.com>,
Brad Midgley <bmidgley@xmission.com>
Subject: Re: [Bluez-devel] Patch: inheritance problem in gsta2dpsink
Date: Tue, 09 Oct 2007 12:01:40 +0200 [thread overview]
Message-ID: <470B5184.1070507@free.fr> (raw)
In-Reply-To: <1191919440.31341.9.camel@aeonflux.holtmann.net>
Hi Marcel, Luiz, Johan, Brad,
>
>> Well, *I do* care.
>> As i told you back in Montpellier, i need a way to plug an external
>> (proprietary) hardware accelerated audio system onto the audio service.
>> In fact i could start working on such a library right away, provided
>> that it is LGPL, so that i can link a proprietary stuff on top of it.
>> Even if it is not packaged as an external library at first, provided i
>> can somehow copy the code out of bluez tree and rebuild a LGPL library
>> out of it would be acceptable as a first step. :-)
>
> I am okay with that. That is not the problem. Having that code under
> LGPL license is no big deal for me. I am actually fully okay with that.
> However please remember that my default license will always be GPL and
> you really have to tell me if you want something different.
Ok, I 100% agree with you : GPL per default, LGPL for "some special
bits" :-)
>
>> If that can't be done then i'm gonna go grumble in a corner and we will
>> have missed an opportunity to move the bluez audio system forward. :-(
>> And remembering what Marcel told us during the meeting, the IPC API is
>> not public because "we don't really know what we're doing".
>> My answer to that is:
>> - having worked on audio stuff for some time now, i think i know what
>> i would be doing if i was to work on this API : which mean it would be
>> made stable pretty quickly.
>> - We'd better start stabilizing the API before too much effort has
>> been put on the gstreamer plugin or any other plugin, otherwise we will
>> have to fix them all afterwards.
>
> This is not gonna work out. You have to deal with API and ABI breakage
> if you are working outside the tree and wanna be closed source. That is
> the price you pay. I don't see any other way around that.
>
> Remember that a lot of things are highly related to the Bluetooth
> specification and A2DP is changing quickly. Actually the versions 1.4
> are already on their way to be getting approved at some point. Also the
> meta data transfer needs some extra love.
I 100% agree with that too. Maybe we just misundertood ourselves about
how "public" it should bet :-)
Basically what i meant is that we should define & stabilize this API for
our own internal use (Gst, ALSA, PulseAudio), and for other people
involved in the Bluez project working also on some out of tree project
(that would be me and maybe the Access guys AFAIK)
However i'm fully aware that this API will break from time to time due
to changes or new features, and won't blame anybody for that :-)
>
> And we need a security audit before ever thinking about making this
> really public and stabilize it.
Well, i didn't mean something *that* public (at least not for now).
I just meant something not-completely-unstable-not-documented-that-
will-keep-changing-and-breaking-my-software-for-no-reason. :-)
So this looks that we agree on everything afterall. :-)
> The LGPL wish is easy to solve. Get Johan and Luiz to agree here on the
> mailing list and then we make ipc.h and an upcoming ipc.c licensed under
> LGPL and then you can copy it out from the bluez-utils source and use
> it.
I was more thinking of as a complete rewrite of ipc.h (we should find it
another name btw : lets call it newipc.h for now ;-) ).
I already started thinking to how i would like to see it look.
It should be relatively lightweight, expose directly a message based API
(as you would find on most RTOS), with just a few functions to create
and free a session to the audio daemon, and to retrieve the data socket,
so that each user wouldn't have to know the tricks about ancilliary data
passing :-)
I fact it should be so lightweight that i think we could static inline
all the functions, and thus we wouldn't even need a *.c file.
I'm waiting for comments, int the meantime i'm gonna start drafting a
newipc.h :-)
Cheers,
Fabien
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel
next prev parent reply other threads:[~2007-10-09 10:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-01 21:31 [Bluez-devel] Patch: inheritance problem in gsta2dpsink thiagoss
2007-10-05 19:36 ` thiagoss
2007-10-08 17:56 ` Luiz Augusto von Dentz
2007-10-08 22:56 ` Marcel Holtmann
2007-10-09 1:32 ` Brad Midgley
2007-10-09 8:01 ` Fabien Chevalier
2007-10-09 8:44 ` Marcel Holtmann
2007-10-09 10:01 ` Fabien Chevalier [this message]
2007-10-09 21:17 ` Luiz Augusto von Dentz
2007-10-10 0:51 ` Marcel Holtmann
2007-10-10 13:31 ` Luiz Augusto von Dentz
2007-10-10 14:09 ` Marcel Holtmann
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=470B5184.1070507@free.fr \
--to=fabchevalier@free.fr \
--cc=bluez-devel@lists.sourceforge.net \
--cc=bmidgley@xmission.com \
--cc=johan.hedberg@nokia.com \
--cc=luiz.dentz@gmail.com \
/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