[Bluez-devel] Use cases for dynamically loading/unloading plugins?

[Bluez-devel] Use cases for dynamically loading/unloading plugins?

[Johan Hedberg]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Use cases for dynamically loading/unloading plugins?

[Jelle de Jong]

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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] Use cases for dynamically loading/unloading plugins?

[Jim Carter]

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: jimc@math.ucla.edu    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
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel