Mailinglist Archive: yast-devel (41 mails)

< Previous Next >
Re: [yast-devel] Some thoughts on the SCR D-Bus service
  • From: Klaus Kaempf <kkaempf@xxxxxxx>
  • Date: Fri, 13 Feb 2009 14:10:19 +0100
  • Message-id: <20090213131019.GA27289@xxxxxxxxxxxxx>
* Ladislav Slezak <lslezak@xxxxxxx> [Feb 13. 2009 13:35]:
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
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

(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

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 ?

SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG N├╝rnberg)

To unsubscribe, e-mail: yast-devel+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: yast-devel+help@xxxxxxxxxxxx

< Previous Next >