Name or Names in service files? (Disconnect between the spec
and our implementation)
hp at redhat.com
Wed Dec 6 09:04:14 PST 2006
Alexander Larsson wrote:
> On Tue, 2006-12-05 at 12:36 -0500, Havoc Pennington wrote:
>> I'd say we have to stick with the implementation at this point, and
>> change the spec. Though the "Names" idea does seem like it was a good
>> one ;-)
> Today I wanted it to support wildcards.
> i.e. "Names=org.gnome.foo.*", and I'd get passed the used name via an
> env var or a commandline argument. Any chance of that happening?
It's certainly possible, though can you explain the use case?
Something to consider (already an issue, but supporting multiple names
makes worse); dbus-daemon tries to avoid starting two copies of
something (if you activate the same name twice it will block both
activators on the same fork/exec of the executable), but to be robust
against multiple copies, the activated app really needs to exit if it
does not get its expected name. This is doubly true if the app can have
multiple names... I think dbus-daemon will start the same app more than
once in that case.
An app with multiple names could have a model where each instance of the
executable has only one of the names, or it could have a model where
some name is the "master name" and any instance that doesn't get the
master name has to exit, and any instance that does must own all the
names the app provides.
I'm not sure we can design .service files in a way to make this easier;
maybe it's just something apps have to get right. But possibly we could
think of something.
More information about the dbus