Help System Spec 0.2

[Aaron J. Seigo]

On Wednesday 27 December 2006 13:14, Thiago Macieira wrote:
> If a service is desktop-dependent, the desktop should acquire the service
> when it starts up. It makes more sense to me than creating a program or
> script that detects the desktop and spawns the correct desktop-dependent
> service.

thiago and i talked about this a bit more on irc...

the annoying thing about claiming the service on startup is that one has to 
either:

a) start the actual application (not good for obvious reasons)
b) claim the service by some long running process (e.g. kded in kde) and when 
a messages is received, start the -actual- application (e.g. kded would start 
khelpcenter) and queue the messages received until khelpcenter takes the 
service over and then relay the messages

personally, the latter gives me the shivers =)

perhaps a better way to do this is to allow customization of the services/ 
directory paths at runtime for a given bus. 

this is already possible in d-bus 1.0, as thiago added 
<standard_session_servicedirs /> which adds ${XDG_DATA_DIRS}/d-bus-1/services 
to the list. unfortunately, this means it has to be done before the bus 
starts, and on some systems the session bus is started before the desktop and 
it means that no post-login modifications are possible (though that's perhaps 
not a bad thing =)

so it was suggested that perhaps we could provide a d-bus call that would add 
dirs to the path ... which isn't perfect either since now we have another 
system for managing these things.

another idea floated was to create a well-known service that a desktop could 
attach to ... it would provide a d-bus interface for querying about services, 
launching them, etc. in lieu of this service being on the bus, d-bus would 
fall back to it's own means which should be enough for basic systems. this 
would allow us to use the service registration controls in d-bus and keep it 
extensible for the future.

this is obviously more work than simply setting an env var, but allows for 
greater flexibility as well as run-time capabilities (inc changes in services 
post-login).

we'd still need a standard way of registering these services, perhaps by 
adding to the xdg autostart spec?, but then at least we could move these 
issues to the desktop level and leave it out of d-bus itself.

in any case, d-bus needs to be told what the preferences are, which means a 
run-time modification of the services. how we do this is the question, and 
one that belongs on the d-bus list i suppose ;)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20061227/93233d67/attachment.pgp