Re: [Evolution-hackers] Regarding API breakage and lost test cases

[Milan Crha <mcrha redhat com>]

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