Am Donnerstag, den 27.08.2009, 22:14 +0300 schrieb Jussi Kukkonen: > 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?
Automatic removing sounds good, as it doesn’t depend on the clients actively removing the lock. So even if one client crashes, the lock could be removed. > >> 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. Yes, I didn’t think of that, sounds reasonable. > 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... I like this idea better, but I’m ok with whatever you come up with in the end. :-) Cheers, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
