services & auto activation

[John (J5) Palmieri]

On Fri, 2008-03-14 at 09:44 -0700, Jim Carter wrote:
> On Fri, 14 Mar 2008, John (J5) Palmieri wrote:
> 
> > On Fri, 2008-03-14 at 11:04 +0100, mehdi bayarassou wrote:
> > > applications through DBus. I want some further information about auto
> > > activation mechanism, .service files, XML descriptor files ( i have
> --snip--
> > If you look in /usr/share/dbus-1/services you can see a number of
> > service examples.  For instance gnome-vfs-daemon.service looks like
> > this:
> > 
> > [D-BUS Service]
> > Name=org.gnome.GnomeVFS.Daemon
> > Exec=/usr/libexec/gnome-vfs-daemon
> 
> Simon McVittie replied to me (paraphrasing): D-Bus provides the channel, 
> you provide the content.  However, I think D-Bus was intended to be not 
> just another IPC mechanism (with filters), but a way to organize the chaos 
> that now forms the Freedesktop.  In this case, what happens if several 
> programs serve the same Service Name?  How does the D-Bus daemon decide 
> which one to auto-start?
> 
> Here's an example.  Suppose Bill Gates at age 19 had been a little more 
> aggressive bringing the UNIX paradigm into MS-DOS (think MS-Minix); let's 
> re-fight the Browser Wars on X-Windows.  Suppose an app has a URL it wants 
> displayed.  Netscape (and Mozilla spawn) have a kludge involving a property 
> on the X-server's root window so the app can deposit the URL and a running 
> Netscape will deal with it.  But this is the D-Bus mailing list: the "right 
> way" is a D-Bus method call, with the significant advantage that the D-Bus 
> daemon can auto-activate the user's preferred browser if no program holds 
> the relevant service name.
> 
> If the user has installed MSIE for UNIX, Netscape-12.x, Firefox, Iceweasel, 
> Mainline Mozilla, W3M and Opera, all of which (in the fantasy scenario) 
> have installed service files, how does the app know which service name to 
> use, and how does the daemon know which is the preferred browser du jour?
> 
> I think Simon would say / has said that the browser community needs to 
> agree on a name and interface.  The D-Bus team could help get this started 
> by saying "you guys need to get on D-Bus and you can use our neutral 
> territory, org.freedesktop.service, to put a generic servce name in."  
> Otherwise each company (think Microsoft) is going to insist on its own 
> incompatible namespace, and the app has no chance of being able to use 
> D-Bus to make a service happen, since it will not know the idiosyncratic 
> names and interfaces that have been or will be kludged together.
> 
> As for preferences, I'd suggest an addition to the service file: the 
> Preference keyword.  The value is an integer; highest wins.  Packagers are 
> instructed to install their service file with a conventional preference of 
> 10; if a distro has a preferred browser the preference should 
> conventionally be set to 20; and the user should have a nice GUI to adjust 
> the numbers to taste; specifically to override the distro's default by 
> setting (e.g.) Opera to have preference 30.  (A case could be made that the 
> distro default should be lower than 10, since if a user explicitly picks a 
> different browser to be installed, presumably he wants it to be used.)
> 
> The names of the service files: must the name match exactly the contained 
> service name?  (All the ones I see in SuSE 10.3 do so.)  Or must it be a 
> prefix?  Or is it arbitrary except for ending in .service?  I'm guessing 
> the latter, since on Maemo-4.0, osso-backup.service says 
> Name=com.nokia.backup.  But if the spec required the filename to have the 
> service name as a prefix, the daemon could identify all relevant service 
> files just by reading the directory, not needing to open every single file 
> (71 of them on Maemo).  If no prefix match were found it could fall back to 
> opening every file.

Patches are thoughtfully considered.  It is either a race condition or
an error if two services are registered for autostarting with the same
name.  I'm not quite sure.  In reality we haven't run into the issue.
Most services which share common names usually are started by the user
and then something which queries it or listens for signals just talks to
whatever the user started.  

I can see however where there would be an issue.  Preferred is most
likely not the best way to do it though since what happens when all apps
install their service file as preferred and you don't want desktop apps
manipulating that file.  What may be possible right now for the session
bus is to link your preferred service into XDG_DATA_HOME/dbus-1/services
which is a just a standard directory in everyone's home directory
usually pointing to .local/share/dbus-1/services/.  This could be done
by some sort of policy daemon but for now by hand should work.  If D-Bus
doesn't pick up the correct service file from the XDG directory then
that is a bug.

-- 
John (J5) Palmieri <johnp at redhat.com>