viability of implementing global shortcuts via KDED and DBus

[Thiago Macieira]

Andreas Hartmetz wrote:
>-What about security? Only real KGlobalAccel objects should be able to
> talk to the KDED module in all circumstances. There seem to be
> provisions for this in DBus, but how do they work, especially in
> QtDBus?

Forget it. There is no security. Anyone can impersonate any object on the 
session bus.

>-How long are typical DBus method invocation times? Shortcuts should
> trigger their actions with no noticeable delay. Assigning saved
> shortcuts to their actions at application startup time should be very
> fast, too.

If the system is idle, the roundtrip should take less than a millisecond.

>-If an application shuts down unexpectedly, can one be 100% sure that
> KDED will get to know it immediately?

No. It depends on the system load. The D-Bus daemon will tell KDED that 
the application exited as soon as it itself finds that out, but how soon 
kded will process that is unknown.

>-Synchronous calls will probably be needed in places where atomic
> updates will be required to prevent race conditions (not sure if that
> happens). Can synchronous calls be made lockup-proof? A locked up
> application should never be able to block the KDED module. On the other
> hand, locked up applications should still receive updates to their
> actions ASAP :/

It can be made lockup proof if you design it so. A synchronous call always 
has the possibility of deadlocking, however. You just have to make it 
extremely unlikely.

-- 
  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: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070511/99fa72be/attachment.sig>