On Mon, Nov 7, 2011 at 2:20 PM, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > 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 > OK, so maybe this fd passing would be confusing and may be problematic if somebody would use java or something. string GetMessage(string file_name, string handle, dict(uint8 tag, variant value)) i think that this is as good as we can settle in this discussion, if there is no serious issues in this model maybe i would start coding it? (I'll resend full api sometime soon) -- 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
