[Authentication] Small specification improvements

[Michael Leupold]

Am 04.12.2010 19:05, schrieb Stef Walter:
> 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.

I wasn't aware dismissed was to be used for both the application and the 
user cancelling. I was under the impression dismissed was only supposed 
to be used if the application cancels using the Dismiss method. I'll add 
some documentation to make that clearer.

>> 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
> makes sense?

Yes, I think it does.

Regards,
Michael