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