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
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,
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
Combined with 1. above, the YaST service would offer objects like
/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
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 !
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
To unsubscribe, e-mail: yast-devel+unsubscribe(a)opensuse.org
For additional commands, e-mail: yast-devel+help(a)opensuse.org