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

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

 



On Thu, Nov 3, 2011 at 4:13 PM, Luiz Augusto von Dentz
<luiz.dentz@xxxxxxxxx> wrote:
> Hi Bartosz,
>
> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote:
>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler <post@xxxxxxxxxxxxxxxxxx> wrote:
>>> Am 03.11.2011 14:44, schrieb Bartosz Szatkowski:
>>>>
>>>>               void SetFolder(boolean cdup, string name)
>>>>
>>>>                       Set working directory for current session.
>>>>
>>>>                       |  cdup  | folder name | operation    |
>>>>                       |=====================================|
>>>>                       | FALSE  | empty       | cd /         |
>>>>                       |--------+-------------+--------------|
>>>>                       | FALSE  | name        | cd name      |
>>>>                       |--------+-------------+--------------|
>>>>                       | TRUE   | [name]      | cd ..[/name] |
>>>>                       +-------------------------------------+
>>>
>>> Why not simply
>>>  void SetFolder(String cdString)
>>>
>>> and derive the obex command from that? It makes that API much easier to use.
>>>
>>> HS
>>>
>>> --
>>> 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
>>>
>>
>> Because it provoke more questions eg. what about failure in the middle
>> of the path? Also i've planned to keep it at rather low level.
>
> Well we can make it only accept only one step at time, which it seems
> is what g_obex_setpath does. Btw what is thing with GetMessage return,
> fd? Do we really need that? Can't we just convert to string so that
> user applications don't have to convert it themselves? Otherwise just
> use an array of bytes ('ay') or pass a path where the message should
> be stored like GetFile. If the concern is that the transfer may take
> too long the client the client should not wait the reply and instead
> track the transfer using an agent.
>
> --
> Luiz Augusto von Dentz
>

And what if you'll start downloading email with 10MB attachment?? So
it's better to send file descriptor through DBus than lots (and lots)
of data. And there is nothing to convert, client will get fd and then
just read message from a file - it's simple enough.

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