KDED Modules and their DBus Path

[Thiago Macieira]

Michael Jansen wrote:
>> One reason for the org.kde.kded /modules/<modulename> naming is that
>> it allows the autoload feature of kded to work (just make a call to a
>> module and it will be loaded if necessary).
>
>That i didn't knew. But that is only of interest for autoload enabled
> modules. And again. I don't like that we expose a implementation detail
> for this purpose.

It's not. I chose the name "/modules/<modulename>" because I liked that 
better than "/<modulename>". That's the only reason why they are there 
right now.

The autoloading feature could be implemented with any path scheme. It just 
has to be deterministic: we have to be able to extract the module name 
from *somewhere*.

>A method like 'gimme service xyz, however that is implemented' would be
> my preferred solution. Is it possible to register a standalone daemon
> under /modules/<modulename> ?

No.

But you can register an auto-startable service with D-Bus. If it's part of 
kded, kded will have to register it when it starts. If it's standalone, 
then D-Bus will launch the application when any application tries to use 
it.

It can even be both.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080422/792916d0/attachment.sig>