[Authentication] Small specification improvements

[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.

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

Cheers,

Stef