On Thu, Nov 3, 2011 at 6:59 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Bartosz, > > On Thu, Nov 3, 2011 at 7:38 PM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: >> 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. > > Then create a transfer object and notify the agent like we do for > GetFile, also with this you progress indication like we have with > normal files and you are also able to catch errors or cancel the > transfer. > > -- > Luiz Augusto von Dentz > 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. -- 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
