start multiple instance of the same service ?

Havoc Pennington hp at redhat.com
Fri Sep 15 08:36:45 PDT 2006


frederic heem wrote:
> Actually, this sounds like writing from scratch a kind of dbus-daemon that is 
> able to launch multiple instance. 

I assure you that this can be done in a few hundred lines and would not 
be close to as complex as dbus-daemon ...

> One idea behind using dbus is too avoid launching application myself but 
> delegates this work to dbus.

You are using glib anyway aren't you? Launching an application is simply 
a matter of g_spawn_command_line("foobar"), it's one line of code.

> What do you think of this proposal ?
> 

It's only useful if there's some difference between the daemon launching 
the thing and some random app launching it. If we implemented that 
launch-as-uid-helper feature, then it makes some sense to me, since 
there's value in having the daemon specifically do the launch.

The specific API needs work. The bus doesn't know anything about 
interface names for services, only about bus names. Currently all 
service launching is done by bus name.

So if we say the service will be launched and will only own a unique bus 
name, no well-known name, there's no way to refer to the service. We 
would probably need to add launch by guid or something like that, i.e. 
in the service file there could be UUID=standard-hex-uuid-as-with-uuidgen

and we could support launch by that, like a COM class ID or something.

Alternatively, the bus could have some support for "composite" bus names 
which is a common pattern, e.g. to make a service unique per network 
interface:
   org.foo.Bar-eth0
   org.foo.Bar-eth1

or to make it unique per user:
   org.foo.Bar-hp
   org.foo.Bar-johnp

etc., you can stick anything on there. Perhaps the API could in some way 
support this common pattern.

With this setup, the app could immediately start sending method calls to 
the bus name and have them be queued up for the service when it finishes 
launching, just as we do for service launches today.

Havoc



More information about the dbus mailing list