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

[Jim Carter <jimc@math.ucla.edu>]

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