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

2013-01-31 Thread Tristan Van Berkom
On 02/01/2013 05:08 AM, Matthew Barnes wrote: On Thu, 2013-01-31 at 20:47 +0100, Milan Crha wrote: 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 anyt

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

2013-01-31 Thread Matthew Barnes
On Thu, 2013-01-31 at 20:47 +0100, Milan Crha wrote: > 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 me

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

2013-01-31 Thread Milan Crha
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 >

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

2013-01-31 Thread Matthew Barnes
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() > retur

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

2013-01-31 Thread Tristan Van Berkom
On 10/06/2012 09:01 AM, Matthew Barnes wrote: On Fri, 2012-10-05 at 22:19 +0900, Tristan Van Berkom wrote: a.) e_source_registry_commit_source_sync() seems not exactly very sync. I haven't looked into that in detail but surely the registry server needs to block on something e