[yast-devel] Some thoughts on the SCR D-Bus service
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
Klaus Kaempf wrote:
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.
Thank you very much for the feedback!
1. service name vs. path name [...] 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)
I agree, "org.opensuse.YaST" is better.
2. path names [...] 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)
I'll adapt it to this upstream convention. BTW is there any reason for that?
3. path name vs. method arguments [...] Currently, the first parameter to the SCR functions (Read, Execute, ...) is a YCPPath. This should be merged with the D-Bus object path.
The problem is that the service would have to recursively find all available objects during introspection. That could take long time and IIRC not all agents return proper Dir() results. Currently I'm working on exporting a Yast namespace on DBus, this approach would need to handle the SCR namespace in a different way than others. I'd like to avoid that. On the other hand there could be additional SCR objects with such interface. -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
* Ladislav Slezak
Klaus Kaempf wrote:
2. path names [...] 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)
I'll adapt it to this upstream convention. BTW is there any reason for that?
I haven't seen any documentation about this. My assumption is that it makes it easier to deal with multiple objects from different services in applications. It probably also helps debugging.
3. path name vs. method arguments [...] Currently, the first parameter to the SCR functions (Read, Execute, ...) is a YCPPath. This should be merged with the D-Bus object path.
The problem is that the service would have to recursively find all available objects during introspection. That could take long time and IIRC not all agents return proper Dir() results.
Right, this indeed makes it complicated. One more reason to fix Dir() in all agents ;-) A good compromise could be to hard code 'well known' agent pathes into the SCR_service, e.g. ".probe", ".target.bash_output", and others. My thinking is mostly driven from coding client applications. So I am trying to make using the service easy, without looking too closely at its implementation. Ideally, the YaST service would offer generic services, completely hiding if the service is implemented by SCR (agent), WFM (ycp code), or whatever. (SCR could also be offered as an Interface, providing 'Read', 'Write', 'Execute' - just a thought)
Currently I'm working on exporting a Yast namespace on DBus, this approach would need to handle the SCR namespace in a different way than others. I'd like to avoid that.
On the other hand there could be additional SCR objects with such interface.
I'm curious to learn more about your approach. Can you share typical (planned) usages of the new api ? 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
Klaus Kaempf wrote:
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) I'll adapt it to this upstream convention. BTW is there any reason for that? I haven't seen any documentation about this. My assumption is that it makes it easier to deal with multiple objects from different services in applications. It probably also helps debugging.
Most conventions are usually not documented as rules but as observations. This is the social part of designing technology. That is why code reading is as (or more) important than code reading. Reading other code gets one the feeling of conventions that are implicitly created across years of maturing a technology. If we are going to jump to dbus, it is good to go and read lot of dbus stuff. If I am going to do python, better I go and read lot of python, or I will end doing rubython and nobody will like it. One learns a lot on the process of understanding the conventions, just as one learns a lot living in a foreign country ;-) Two good examples I see where conventions are "hard" is Qt and ruby: http://doc.trolltech.com/qq/qq13-apis.html, there you will find even "The Art of Naming". Good read even for non-Qt people. Thats why I am happy Klaus took the time to go and see how the others do it too, because most of the times small details have a reason, and a small wrong choice is hard to step back later. -- Duncan Mac-Vicar P. - Engineering Manager, YaST SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
I'm not sure how relevant (or correct) it is, but as I stumbled upon it already and it could be eventually relevant I thought I post it here: http://0pointer.de/blog/projects/versioning-dbus.html Michal -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org For additional commands, e-mail: yast-devel+help@opensuse.org
participants (4)
-
Duncan Mac-Vicar Prett -
Klaus Kaempf -
Ladislav Slezak -
Michal Svec