DBus/QtDBus Concerns

[David Jarvie]

On Thursday 13 July 2006 14:43, Thomas Zander wrote: 
>On Thursday 13 July 2006 12:55, David Jarvie wrote: 
>> On Thursday 13 Jul 2006 10:31, Thomas Zander wrote: 
>> >On Thursday 13 July 2006 01:50, David Jarvie wrote: 
>> >> KAlarm and kalarmd need to interact via D-Bus. If some other 
>> >> application made certain D-Bus calls, alarms could be lost. 
>> > 
>> >Only if those applications were malicious. If you expect things to get 
>> >lost due to bugs, I suggest you take a long look at the interaction 
>> > you have via dbus since that may need some work ;) 
>> 
>> I'm thinking more in terms of people trying to do clever things with 
>> the "private" interface, which might mess things up. 
> 
>Bugs have to be fixed; this has nothing to do with the transport medium. 
>Its like Windows saying it will only send emails to other Windows boxes 
>since others might loose it. I won't even comment on how wrong that is. 

But if it was possible to check the sender, it would eliminate any possibility of such bugs. 

>> >What you are suggesting is to close the alarms modification to one 
>> > client only. I think this is fundamentally the wrong path to walk 
>> > down. 
>... 
>> The alarm daemon never adds, deletes or modifies alarms. Only KAlarm 
>> can do this, and it has public D-Bus functions for this purpose. 
> 
>So, you really are suggesting that nobody can create a KAlarm replacement 
>that talks to the KAlarm daemon via dbus? 

No, in theory you should be able to run the daemon with a different client (but not 
simultaneously with KAlarm). In KDE 3, the daemon records which application has registered 
with it, and only processes subsequent DCOP messages from that application. I want to use 
the same checking in KDE 4. 

-- 
David Jarvie. 
KAlarm author & maintainer. 
http://www.astrojar.org.uk/linux/kalarm.html