On Thu, 2009-08-27 at 20:14 +0100, Jussi Kukkonen wrote: > 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.
That definitely is the plan. I already have the necessary "Watch" class in the C++ binding. > Is that (clients exiting) > the only problematic situation? That's really a question to the client developers ;-) Suppose the user wants to edit the configuration while a sync runs. You submit a StartSession and then don't get the session in a certain amount of time. Would it be useful to pop up a dialog explaining the problem with an abort button? If the user aborts, then the client should keep running and cancel the session. If it doesn't cancel, then it will end up owning the session eventually, completely locking the server. > >> 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. That's bad. The Connect.Process method is based on the assumption that processing the message may take arbitrary amount of time. If the D-Bus server enforces a maximum duration, then the API must be changed. Grr. > 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... This would be better. In other words, assign a session number in advance and thus create an object path that is returned by StartSession, but without really activating that object on D-Bus. Then when it has the lock, activate it and send out the SessionReady signal on the server. Avoids the race condition because clients can register for that signal before asking for a session. -- 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
