Re: [PATCH obexd v0 05/12] client-doc: Replace SendFiles with SendFile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Luiz,

On Mon, May 21, 2012 at 11:33 AM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Mikel,
>
> On Mon, May 21, 2012 at 12:07 PM, Mikel Astiz <mikel.astiz.oss@xxxxxxxxx> wrote:
>> From: Mikel Astiz <mikel.astiz@xxxxxxxxxxxx>
>>
>> Now that OPP sessions exist, sending multiple files can be achieved with
>> consecutive calls to SendFile. Note that within a session the pending
>> operations will be queued and sequentially executed.
>> ---
>>  doc/client-api.txt |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/client-api.txt b/doc/client-api.txt
>> index 32caa17..de726a8 100644
>> --- a/doc/client-api.txt
>> +++ b/doc/client-api.txt
>> @@ -65,9 +65,9 @@ Service               org.openobex.client
>>  Interface      org.openobex.ObjectPush
>>  Object path    [variable prefix]/{session0,session1,...}
>>
>> -Methods                void SendFiles(array{string} files)
>> +Methods                void SendFile(string sourcefile)
>>
>> -                       Send one or multiple local files to the remote device.
>> +                       Send one local file to the remote device.
>>
>>                void PullBusinessCard(string targetfile)
>>
>> --
>> 1.7.7.6
>
> Perhaps it is a good idea to return the transfer object here, so the
> application can track the progress and cancel it which is the whole
> point of not having multiple files so we can do this properly.

It is a good idea indeed, but I was planning to do this in a later
patch along with the rest of the API, for example PullBusinessCard.
Most of the D-Bus interfaces will need such a transition in fact.

In addition, this change does make some sense on its own, since it
maps better to the OBEX spec. IIRC SendFiles was there to avoid
creating one session per transfer, but this is no longer a problem
once OPP is wrapped in a session type. It also allows to have a
asynchronous call, so the client can wait until the transfer is
finished.

So I can merge both changes but I would rather keep them separated, so
we can have more consistent APIs after each step.

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


[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux