Hi, after having learned about D-Bus in general and the YaST SCR_service in particular, I'd like to share my thoughts on what I saw. 1. service name vs. path name The service name used for SCR_service is "org.opensuse.yast.SCR", offering a single object under the path name "/SCR". This seems to duplicate the namespace (SCR) and would make further extensions (i.e. 'WFM', or 'YCP' to run pure ycp code) look like different services. We might as well use "org.opensuse.YaST" as a generic service name and have the namespace as part of the object path. Note the use of upper case for YaST which matches other service names on the system bus (org.freedesktop.Avahi, org.freedesktop.ConsoleKit, org.freedesktop.Hal) 2. path names Introspecting other D-Bus services shows that all of them repeat the service name as part of the path prefix. I.e. service org.freedesktop.Hal offers /org/freedesktop/Hal/devices/* Combined with 1. above, the YaST service would offer objects like /org/opensuse/YaST/SCR, /org/opensuse/YaST/WFM, /org/opensuse/YaST/YCP. (Alternatively, /org/opensuse/YaST/scr might get better acceptance upstream) 3. path name vs. method arguments Looking at Hal object pathes like /org/freedesktop/Hal/devices/pci_8086_3a02_scsi_host_1_scsi_device_lun0 and the SCR_service interface methods, it occured to me that the API could be simplified. Currently, the first parameter to the SCR functions (Read, Execute, ...) is a YCPPath. This should be merged with the D-Bus object path. So instead of retrieving a single /SCR object and calling res = interface.Read(".probe.cpu") [simplified code, reality looks different !] the object path should be /org/opensuse/YaST/scr/probe/cpu offering a simple 'read' function. Comments welcome ! Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org