On Thu, 2013-01-31 at 08:11 -0500, Matthew Barnes wrote: > On Thu, 2013-01-31 at 18:25 +0900, Tristan Van Berkom wrote: > > I'm not sure what the solution should be exactly, but we > > should discuss this a bit because the problem space is > > a little bigger than just the source existing in the > > client-side before e_source_registry_commit_source_sync() > > returns. > > Note that e_source_registry_commit_source_sync() is just a convenience > wrapper. If your test cases are just passing scratch sources then what > you're actually calling is e_source_registry_create_sources_sync(). > That's the function I fixed in bug 685986. > > > > So I guess there are 2 potential ways of addressing this problem: > > There's a 3rd approach. >....
Hi, I vote for Tristan's 2), basically because it's the right approach in client-server architecture, also used in evo-mapi (and maybe in evo-ews, I do not know). Basically, if client doesn't have anything it was asked for, then it doesn't mean that the server doesn't have it too. The other things about the 3) I do not like: a) the point of changing book/cal APIs to not provide XML blobs of sources, but only UIDs was initiated and done by you, if I recall correctly, why to return back then? b) double commits? It might be about unnecessary overhead and double disk write/D-Bus noise too. I guess I got it right, because if it'll be only one commit and not two, then having a book factory creating the ESource, and still use it in the test/client code means that you still wait for a signal from the registry about source-added or whatever, which is basically no gain from the current state, only more complicated (D-Bus) API and giving a decision on the client whether to use one or the other function to open a book. Tristan's 2) can do all this transparently, without any API change on client side, maybe only a little change on the registry D-Bus API (adding function probably, I do not know). Anyway, I believe that keeping things simple is always a gain. Not that it's always possible, but why to confuse people by strange API? (Like those two 'remove' functions, and now proposed two opens.) Bye, Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers