On Thu, 2012-03-15 at 18:06 +0100, Krzesimir Nowak wrote: > W dniu 15 marca 2012 17:54 użytkownik Krzesimir Nowak > >> So it seems to me that this is the right way to go. Regarding the code, > >> can we introduce flags for dbus_get_bus_connection() instead of creating > >> multiple copies of it? That'll scale better in case that we find a need > >> for other variations. > > > > That is almost exactly what I did - but instead of adding flags I just > > added a bool parameter. Right now I am creating some commits. I will > > let you know when I push this. > > Pushed here (forced update): > https://meego.gitorious.org/~krnowak/meego-middleware/krnowaks-syncevolution/commits/css-with-direct-msg-proc
Note that nothing in your GDBus C++ commit messages or code explains what "delayed connection" is, and how it might be used. Please remember to include explanations to the code (as API description) and/or commit messages (to give additional information). I've merged that into concurrent-sync-pohly anyway. Instead of removing the dead code manually, I dropped the commits which introduced it from the branch. Result is in concurrent-sync-pohly-delayed-dbus. In which case would it be useful to use ForkExecChild::connect(delayed = false), the default? I can't think of any, and thus would always delay internally. Even if the we keep the parameter, the default is dangerous because it leads to the race condition and thus should be the other way around. The new branch uses the -resource variant of naming the session and connection class in the syncevo-dbus-server side. I ended up using that because it had less conflicts with the changes that I had made for password handling - so a purely pragmatic decision. I'm still not happy with the naming, but that can wait. Please base all future work on that. -- 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
