Patrick Ohly wrote:
On Thu, 2009-08-27 at 17:45 +0100, Frederik Elwert wrote:
Just one question to help me understand: Why would I need the object
path until the session is locked?
If the client finds that it no longer needs the lock, it can call a
method on that object to cancel it. Hmm, do we really need this in
practice?
It is part of the Connect interface, and for a good reason in that case.
For the GUI it might be overkill.
Yeah, this was the original reasoning. I'm pretty sure the server could
keep an eye on clients that start a session, automatically removing the
lock if the client disappears from the bus. Is that (clients exiting)
the only problematic situation?
Couldn’t one make StartSession return
the object path just when the lock is acquired? Then it would of course
make sense to call this method asynchronous, at least for GUI clients.
We could add a parameter to StartSession which let's the client choose
whether he wants the object returned immediate in the "unlocked" state
or whether he wants to block.
Ah yes, this was the other problem: I'm not sure what the D-Bus method
timeout is nowadays but we could definitely hit it here... So whether
the method call is async or not, it should not take minutes to complete.
I do think the method should return immediately and a signal is needed.
The signal could of course be SessionReady in the Sync (or Server)
object so that the object is only created at that time, if that sounds
better than the original idea...
- Jussi
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
