Re: [RFC] API for MAP client in obex-client

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

 



On Fri, Nov 4, 2011 at 1:00 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 9:01 PM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote:
>>
>> Generally you may be right, but i'm not sure whether actually tangling
>> agent (client of the client?) is a good idea -- I'll check it
>> tomorrow, but AFAIR it's  an additional reversed connection? And
>> situation with this big message probably is not so often to cause such
>> a confusion. I would really like to use such API in simplest possible
>> way, by calling some method and receiving answer and its exactly what
>> is accomplished with fd.
>
> I haven't seen the implementation but I have a feeling it won't be
> that simple, if you use the pipe/unix socket to stream the data them
> you end up copying data and the stream still need to be handled  in
> client side which will very likely copy/convert the data again. We
> have tried such a thing before with A2DP and it was consider
> inefficient, so what we do nowadays is passing the bluetooth socket
> itself to PulseAudio but note that here it would not be a good idea
> since the client would have to deal with OBEX protocol directly.
>
> You could return the transfer object on GetMessage, actually is is
> probably a good idea to do this also for GetFile/PutFile, so that the
> caller application have direct control on the transfers it has started
> and we can probable have a property e.g. Status (Transferring, Error,
> Complete) to indicate the transfer status, that would remove the need
> to have an agent in the application although the system may still have
> one to track the progress and keep history of the transfers.
>
> --
> Luiz Augusto von Dentz
>

As far as i can tell adding transfer would be good idea and it's not
necessary to actually track it. But there is still question how to
transfer data? I'm still convinced that passing fd is good idea, maybe
even more flexible would be to pass it from user to obex-client in
DBus call, so user may decide whether it would be more convenience to
use file, pipe or whatever.

So method may look something like this:

string GetMessage(unix_fd msgfd, string handle, dict(uint8 tag, variant value))

Returning path to the newly created transfer.

-- 
Pozdrowienia - Cheers,
Bartosz Szatkowski
--
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