DCOP D-BUS HAL and new cd's

Jérôme Lodewyck lodewyck at clipper.ens.fr
Fri Sep 17 09:00:27 BST 2004


	So, Let's start with hardware discussions...

	I propose the following framework as a starting point for our discussions. It 
is inspired from discussion I had with Kévin, from the work I have done on 
kvm, and from the current devices implementation. Kévin has already started 
an implementation of a new devices kded on his own, so he will surely be able 
to correct this view.

	The main idea is that we need a replacement for the current devices 
kioslave/kded that can handle more types of media (not only mountable media), 
with the possibility to connect to external tools (think of the HAL) if 

	So we need :

- A kded daemon (a mountwatcher replacement). Following our "mission 
statement" edicted by Kévin, this daemon shall not depend on external tools, 
or on any OS (it should work from Linux to Win32/qt). So do not expect a 
/etc/fstab file, or do not rely on HAL calls.
This daemon is responsible for listing devices, and provides a DCOP interface 
to emit device properties upon demand. It should also provide an interface 
(not sure of what type : API or DCOP -- I favour API) so that "external 
modules" (see below) can tell it which devices are available, and can notify 
it upon device insertion/removal...
Optionnaly, this daemon could implement autoplaying policy (think of 
automounting, CD/DVD playing...), triggered if an external module can provide 
insertion notification (code for this already exists in kvm).

- A "(K)Device" class that stores properties about a device. For example, it 
should countain a QString identifier (given by external modules), if it is 
mountable, information about mountpoint, an URL, a mimetype... This class 
should be accessible from external modules.

- A kioslave (much like devices:/) that create kfile entries corresponding to 
the daemon device list. Before requesting devices mounting, it should ensure 
the device is mountable. If not, it should rely on the URL provided by the 
device class.

- External modules : these modules should implement OS/tools specific device 
detection. For example :
	* A "fstab/mtab" module, that gathers fstab watching as currently done by the 
	* A HAL modules
	* A win32 module ?
Modules should ne able to override each other. e.g, if HAL is running, the HAL 
module should override the fstab modules since the user/ditributer decided to 
use HAL.

- Additional mimetypes, e.g. video_dvd, audio_cd, mixed_cd, gphoto2_camera... 
and additional "Desktop Actions", e.g. play for video_dvd and audio_cd...

Please complete/correct

Jérôme Lodewyck

More information about the kde-core-devel mailing list