Hi,
As you may know recent BlueZ versions (since 3.30) and the upcoming
4.x branch will use plugins for several different purposes, including
local bluetooth services (e.g. audio, input, network, etc) which were
previously implemented as separate processes. For the separate process
case we had an API for starting and stopping services but currently
there is no D-Bus methods planned to allow loading or unloading of
plugins at runtime. Instead, there only is a configuration file (/etc/
bluetooth/main.conf added in 3.32) which can be used to specify which
plugins should not be loaded when hcid starts.
We were today debating with the developers whether it would be useful
to have a D-Bus API for dynamically loading and unloading of installed
plugins but couldn't really reach a consensus. Personally I have a
"gut" feeling that these would be good to have but don't really have a
really good use case for it. Marcel otoh doesn't feel a need for it
and won't add the API without good use cases. So, we would like to
hear any needs (with use cases) that people on this list might have
for this feature.
Johan
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
On Fri, 30 May 2008, Johan Hedberg wrote:
> We were today debating with the developers whether it would be useful
> to have a D-Bus API for dynamically loading and unloading of installed
> plugins ... So, we would like to
> hear any needs (with use cases) that people on this list might have
> for this feature.
I'm using my Nokia 770 with 64 Mb RAM and no swap file. Having finished
listening to classic Lawrence Welk MP3's :-) I want to run the web browser,
which is a memory hog. A2DP service, go away!
Incoming voice chat: I want to listen/talk to it now, not after a massive
0.5 Mb of shared libraries are mapped. I would want HSP/HFP ready to go,
starting from boot, if I were into voice chat. But with the option to shut
it down if I have a resource problem.
I do the pairing procedure on a new Bluetooth keyboard or mouse.
Presumably I now want to actually type something. hcid would automatically
load the plugin for HID, right?
Returning to the voice chat case, it's tempting to add to the chat software
(ekiga? gizmo? skype?) a feature to send the "prepare HSP" message when
it starts up, but I think that's commingling protocol layers. I'm not
really expert in audio multiplexing, but I believe the PulseAudio people
are talking about creating their own plugin for a Bluetooth sink or source,
that knows the Bluez API and could potentially send such a message. Or
maybe the better place is in ALSA, when the Bluetooth audio sink/source is
actually opened. Or even better (or worse?), it should be possible to
begin to open the source/sink with nothing connected to it, and the Bluez
side will take care of loading the plugin and *finding* a headset to
connect to the source/sink. (If there were none, the open would eventually
fail.)
On the API details, I think it's a really bad idea to entitle the method
call "load plugin" or "get rid of plugin", because it commits the
implementer to actually having plugins that can be loaded -- as well as
committing in advance to the names of the plugins. I would prefer to
advertise the method as "prepare for quick action on [protocol]", or "done
with [protocol] for now". The names of the protocols are defined in the
Bluetooth spec, and presumably software developers can rely on them to not
change.
I'm thinking about automatically unloading plugins after a period of
non-use. I wonder if the timeout should be a parameter to the "prepare
protocol" method, or should be in a static configuration file, or both.
Here's another use case: one of the plugins has a bug. Often (but far from
always) you can work around bugs by unloading the plugin and reloading it.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 520 Portola Plaza; Los Angeles, CA, USA 90095-1555
Email: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Johan Hedberg wrote:
> Hi,
>
> As you may know recent BlueZ versions (since 3.30) and the upcoming
> 4.x branch will use plugins for several different purposes, including
> local bluetooth services (e.g. audio, input, network, etc) which were
> previously implemented as separate processes. For the separate process
> case we had an API for starting and stopping services but currently
> there is no D-Bus methods planned to allow loading or unloading of
> plugins at runtime. Instead, there only is a configuration file (/etc/
> bluetooth/main.conf added in 3.32) which can be used to specify which
> plugins should not be loaded when hcid starts.
>
> We were today debating with the developers whether it would be useful
> to have a D-Bus API for dynamically loading and unloading of installed
> plugins but couldn't really reach a consensus. Personally I have a
> "gut" feeling that these would be good to have but don't really have a
> really good use case for it. Marcel otoh doesn't feel a need for it
> and won't add the API without good use cases. So, we would like to
> hear any needs (with use cases) that people on this list might have
> for this feature.
>
> Johan
From a general point of view, I would say the following:
Dynamically loading functionality is an very good thing! This means no
resources are lost during startup and only features are only loaded when
needed.
If we uses bluez in a mobile device, resources take up power and speed.
Having a dynamic feature that loads "input" and "audio" plugins when
such devices really are connected would be a great. No need for users to
manually enable disable features.
Both from usability and technical point of view i would suggest
dynamically loading and unloading plugins.
Thanks in advance,
Jelle
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel