On Wed, 2013-06-26 at 16:10 +0200, Patrick Ohly wrote:
On Mon, 2013-06-10 at 12:35 +0200, Lukas Zeller wrote:
On 10.06.2013, at 11:57, Patrick Ohly patrick.o...@intel.com wrote:
I'll probably try something else: if commands were delayed in a
message which is marked Final, then force
Hello Patrick,
On 10.06.2013, at 11:57, Patrick Ohly patrick.o...@intel.com wrote:
Looking at it like that, the question becomes: how does the server
decided that it still needs an answer from the client?
Perhaps the problem is on the client side after all: in message msgID=2,
the client
On Mon, 2013-06-10 at 12:35 +0200, Lukas Zeller wrote:
On 10.06.2013, at 11:57, Patrick Ohly patrick.o...@intel.com wrote:
I'll probably try something else: if commands were delayed in a
message which is marked Final, then force execution of the commands at
the end of processing that
On Mon, 2013-06-03 at 22:17 +0200, Lukas Zeller wrote:
How about yet another approach: the store is allowed to return a new
error code, LOCERR_AGAIN, for add/update/delete operations. The engine
then remembers all operations with that return code and calls them again
(with the exact same
Hello!
I'm trying to batch local database adds together to increase performance
in SyncEvolution (https://bugs.freedesktop.org/show_bug.cgi?id=52669 and
https://bugs.freedesktop.org/show_bug.cgi?id=64838#c5).
My hope was that I can postpone the actual modification and return a
temporary local
Hello Patrick,
FinalizeLocalID came into existence as a workaround for the iOS client
datastores, in particular the address book which did not generate proper IDs
until a very expensive save all method was called. I tried to implement it as
generically as possible, but avoiding any extra risk
