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
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
