Am Freitag, den 17.09.2010, 10:02 +0200 schrieb Patrick Ohly: > On Do, 2010-09-16 at 21:10 +0100, Frederik Elwert wrote: > > From Genesis’ side, I could catch the exceptions and ignore them (i.e., > > act as I did before the new methods were introduced). Should work, but > > maybe is not really pretty. Another idea would be to allow other clients > > to Attach() to sessions to prevent them from terminating before they are > > dealt with. > > That *is* already allowed :-) Whether it works is a different question, > but it should.
Oh, I missed that. Regarding to [1], there is a Detach() method, but not Attach(). But maybe that’t not even required. [1] http://meego.gitorious.org/meego-middleware/syncevolution/blobs/master/src/dbus/interfaces/syncevo-session-full.xml > > But I don’t know if this is really reasonable. > > I think it is. You still have a race condition, though. The Attach() > method itself may arrive too late. In that case it seems reasonable to > me to catch the exception and ignore the session. I do now catch the exceptions, but this is not really a final solution. Ignoring sessions that throw the exception would break result reporting for sync-ui sessions altogether, and just ignoring the exceptions brings us to the old situation before the new features were introduced. > I could also introduce a delayed clean up of completed sessions. For > example, keep them around 1 minute after the last client has detached, > just in case that someone is still interested in the session's > attributes. In my eyes, this sounds like a very simple and good solution. It gives clients enough time to request session information (or attach to the session if they need it to exist longer than the built-in interval). Regards, Frederik _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
