kioslaves and asynchronous kpasswdserver calls

Michael Leupold lemma at
Mon Apr 20 19:17:40 BST 2009

Hash: SHA1

Thiago Macieira wrote:
> Em Segunda-feira 20 Abril 2009, às 18:19:49, Michael Leupold escreveu:
>> Lubos Lunak wrote:
>> > On Monday 20 of April 2009, Michael Leupold wrote:
>> >> Hi,
>> >>
>> >> I committed a new asynchronous interface for kpasswdserver last week.
>> >> It fixes timeout issues if the user doesn't answer the password dialog
>> >> within the D-Bus timeout interval.
>> >
>> >  I must be missing something important, since this is a stupid
>> >  question: Why
>> > not simply increase the timeout for the D-Bus call?
>> The D-Bus timeout is limited by the timeout you set on making the call
>> and the maximum timeout allowed by the daemon. The current default
>> timeout D-Bus ships with is 300s. We can't really influence it as it's up
>> to D-Bus and the distributions configuring it.
> That's true, but I'd say that the ioslave should give up on the password
> after 300s. In fact, the application will probably kill it before that.
> I know you implemented this type of API to handle the broad use-case in
> applications where the timeout could be much higher. But for ioslaves,
> especially considering there's an application waiting for it too with
> timeouts, I'm not sure this is that useful.

Even if we don't want a kioslave to wait for a password that long the 
approach still has the benefit of giving the slave complete control about 
it, eg. the API could be changed to allow to use an arbitrary timeout we 

I think a timeout of 300s can even be too low for a kioslave. Just imagine 
logging on and walking away to have a coffee and a quick chat before your 
session is fully restored. When you come back you'll find error 

Personally I'd prefer no-timeout D-Bus operations because it makes dealing 
with method calls a lot less complex but that's not there (yet?).

Version: GnuPG v1.4.6 (GNU/Linux)


More information about the kde-core-devel mailing list