kioslaves and asynchronous kpasswdserver calls
lemma at confuego.org
Mon Apr 20 19:17:40 BST 2009
-----BEGIN PGP SIGNED MESSAGE-----
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?).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-core-devel