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. > > 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. > > 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. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
