Name or Names in service files? (Disconnect between the spec and our implementation)

[Havoc Pennington]

Alexander Larsson wrote:
> On Tue, 2006-12-05 at 12:36 -0500, Havoc Pennington wrote:
>> Hi,
>>
>> 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.

Havoc