Hi Bartosz, On Mon, Nov 7, 2011 at 2:42 PM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: > On Mon, Nov 7, 2011 at 11:37 AM, Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: >> Hi Bartosz, >> >> On Mon, Nov 7, 2011 at 11:46 AM, Bartosz Szatkowski <bulislaw@xxxxxxxxx> wrote: >>> 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. >> >> As I told you passing a fd to pass data is not very efficient because >> you are just adding an intermediate buffer since obexd will have to >> copy from the socket to the fd where the client read (btw buffering >> the whole message in the client is probably a bad idea), in the other >> hand the fd could be of a file that would probably work better but it >> is no much different than passing a path which was my initial >> suggestion and is probably simpler to implement because we have been >> doing this already. This way when the transfer is completed it just a >> matter of reading the file. >> >> -- >> Luiz Augusto von Dentz >> > > Generally GetMessage (x-bt/message) is set to be buffered in > obc_transfer_get - so there is (AFAICT) no real difference what we > would do with this buffer. And if we would like to modify it to use > file buffering, we can use usr provided fd rather then file name and > let client decide where to store it. In sake of user app simplicity, > as you say earlier. That is nothing that couldn't be changed, also whether it is a path or not the user is still deciding where it should be stored but I guess a path is actually less troublesome to the client to deal with since not every binding supports fd passing which can be a problem to end user application which I suppose this API should be targeting, also using paths is consistent with other parts of the code GetFile/PutFile. -- Luiz Augusto von Dentz -- 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
