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