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