GNOME Bugzilla – Bug 697106
DRA: fix opening
Last modified: 2013-04-05 06:40:59 UTC
Opening an address book in DRA has several problems: - The client must wait for the D-Bus server to finish opening before opening the same database. Not doing so leads to a race condition which can lead to read failures because the database is not ready yet. - e_client_connect_direct_sync must be usable from Vala. Currently there seems to be no binding for it. - There must be an asynchronous e_client_connect_direct for this. Both folks and SyncEvolution's syncevo-dbus-server call this in their main event loop and should better not be blocked in a synchronous call.
Created attachment 240388 [details] [review] quick fix for open ordering FYIO, this is a quick fix for the code in the 3.6.x based DRA ("openismus-work").
Tristan, is this the right fix for openismus-work? I've already pushed it as openismus-work-pohly.
Patrick. The patch looks logical to me. I wouldn't worry so much about the direct opening logic to not be cancellable for now, but indeed for master we should have something cleaner for the async open (the difficulty in that is kindof the reason why I left the async e_book_client_connect_direct() API out of master so close to the 3.8 release). Rationale is basically that: a.) For openismus-work, we are only really interested in the file backend, so opening the book is really synchronous, the detail that there is a thread is only an abstraction of EDataBook. b.) We want to really use the async methods in the case that any other backends implement DRA eventually. Which is IMO worth doing, since most other backends do implement some caching, implementing DRA for ldap or google backends still brings good performance benefits. Other backends can have justifiable reasons for the async ->open() semanitics.
Closing this one, as I see it's applied to openismus-work branch. And it does not apply to master / 3.8 (in master and 3.8 the normal access client connection is always made before the direct connection is made).