Hi Patrick, > On Tue, 2012-08-21 at 09:26 +0200, Mikel Astiz wrote: > > > You can set up operations in this order: > > > 1. Create temporary file. > > > > Is there any particular reason not to let obex-client create the temporary > file? > > Have you seen my email on the Bluez list about using the obexd client API > correctly? > > http://thread.gmane.org/gmane.linux.bluez.kernel/28481 > > The reason why I am suggesting to use a temporary file under control of the > client is that SyncEvolution has more control about cleaning up in case of > failures. > > When obexd chooses a file name, who is responsible for deleting it in error > cases like "client fails to take the file"? > > When SyncEvolution chooses the path, it can guarantee that it is somewhere > where either the system (/tmp/) or SyncEvolution itself (some cache > directory, to be implemented) will garbage-collect old obsolete files.
Now I understand the problem. Perhaps we should consider modifications in the API as you suggested in the other thread. > > > 2. Create a SignalWatch for all object paths which updates > > > status > > > > A possible optimization here would be using path prefixes, so you can > > focus on transfers belonging to your own session. > > If the obexd API makes such guarantees, then they should be documented ;- > ) Right now, client-api.txt only says that the Transfer > object has "Object path [variable prefix]/{transfer0,transfer1,...}" > - there's no indication at all that "variable prefix" is related to the > session > path. Indeed, I already sent a patch to fix the documentation. > > > if the Transfer's Filename matches the temporary file. > > > > I'd rather check the object path instead of the filename (of course you > need to start the transfer first). > > And that's where you run into the race condition that I described in my mail > to the Bluez list: by the time that the SignalWatch is set up, the client > might > already have missed the signals that it wants to receive. I still don't get the problem. I was proposing to install the watch with the session prefix, not the full transfer path. Of course this relies on the undocumented prefix string in the API. Am I missing something? Cheers, Mikel _______________________________________________ SyncEvolution mailing list SyncEvolution@syncevolution.org http://lists.syncevolution.org/listinfo/syncevolution