Hi Luiz,
On Fri, May 25, 2012 at 12:50 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Mikel,
>
> On Fri, May 25, 2012 at 1:11 PM, Mikel Astiz <mikel.astiz.oss@xxxxxxxxx> wrote:
>> From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx>
>>
>> These signals replace the old agent-based notification mechanism.
>> ---
>> doc/client-api.txt | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/doc/client-api.txt b/doc/client-api.txt
>> index cc25543..527df05 100644
>> --- a/doc/client-api.txt
>> +++ b/doc/client-api.txt
>> @@ -322,6 +322,15 @@ Signals PropertyChanged(string name, variant value)
>> This signal indicates a changed value of the given
>> property.
>>
>> + void Complete()
>> +
>> + Informs that the transfer has completed successfully.
>> +
>> + void Error(string message)
>> +
>> + Informs that the transfer has been terminated because
>> + of some error.
>> +
>
> To avoid any possible confusion I would leave a single signal to tell
> it is complete e.g. Complete(string message), as for the error Johan
> suggested something more meaningful like D-Bus error which both error
> code and error message e.g. Complete(string code, string message),
> actually maybe we should give some other detail when the transfer is
> completed such as file location and other properties that might be
> useful since once this signal is emitted the transfer is gone so there
> is no way to retrieve this information again.
OK, I will change to Complete(string code, string message), although I
have to say I don't like it very much.
So in that case, we would emit Complete("", "") in case of success, right?
Regarding returning transfer properties, that should not be necessary
because, as we already discussed, the idea was to return these
properties in the transfer-initiating method.
Cheers,
Mikel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
