Return-Path: MIME-Version: 1.0 In-Reply-To: References: Date: Thu, 3 Nov 2011 20:01:36 +0100 Message-ID: Subject: Re: [RFC] API for MAP client in obex-client From: Bartosz Szatkowski To: Luiz Augusto von Dentz Cc: Hendrik Sattler , linux-bluetooth Content-Type: text/plain; charset=UTF-8 Sender: linux-bluetooth-owner@vger.kernel.org List-ID: On Thu, Nov 3, 2011 at 6:59 PM, Luiz Augusto von Dentz wrote: > Hi Bartosz, > > On Thu, Nov 3, 2011 at 7:38 PM, Bartosz Szatkowski wrote: >> On Thu, Nov 3, 2011 at 4:13 PM, Luiz Augusto von Dentz >> wrote: >>> Hi Bartosz, >>> >>> On Thu, Nov 3, 2011 at 4:16 PM, Bartosz Szatkowski wrote: >>>> On Thu, Nov 3, 2011 at 3:08 PM, Hendrik Sattler 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@vger.kernel.org >>>>> 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