[Authentication] Small specification improvements
stefw at collabora.co.uk
Sat Dec 4 10:05:51 PST 2010
On 2010-09-25 14:44, Michael Leupold wrote:
> 1. When using Prompt objects there's currently no way to signal a specific
> error to the caller - though most calls can use an "invalid" return value to
> indicate failure:
> - CreateCollection/CreateItem => '/'
> - Unlock/Lock => item's ObjectPath is not in the unlocked/locked array
> Usually that's not much of a problem, ie. if creating or unlocking a
> collection fails the caller could just ask the user what to do ("Saving your
> mail password failed. Do you want to retry?"). There is however one case this
> does not make sense in: an operation failing because the user cancelled it.
> Possible solution: the org.freedesktop.Secret.Prompt.Completed signal gets an
> additional "OUT Boolean cancelled" argument.
I thought that's why we had the 'dismissed' signal. If either the user
or the calling application cancels a prompt, then the 'Completed' signal
is emitted with the 'dismissed' argument set to TRUE.
> 2. There might be other reasons why calls fail in addition to the ones
> mentioned in chapter 14 (eg. resource limitations). Is it alright to add
> something along the lines "In addition to the errors mentioned here, clients
> should be prepared to receive any of the org.freedesktop.DBus.Error errors"?
Yes, certainly. In addition clients will get errors if they pass bad
arguments, or call functions that don't exist. But I imagine they would
only have special handling for a few specific errors that are noted in
the spec, and all other errors would be handled generically. Does that
More information about the Authentication