On Fri, 2009-07-24 at 20:20 +0200, Patrick Ohly wrote:
Hello!
Let's pick up this discussion again. When we agree on the API changes,
then I'll try to follow up with an implementation for the file backend.
On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
Hello Suman!
I forgot
Hello!
Let's pick up this discussion again. When we agree on the API changes,
then I'll try to follow up with an implementation for the file backend.
On Thu, 2009-01-08 at 13:48 +0100, Patrick Ohly wrote:
Hello Suman!
I forgot to ask: do you agree in general with the plan to do atomic
On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote:
On Wed, Jan 7, 2009 at 17:15, Patrick Ohly patrick.o...@gmx.de wrote:
The plan for change tracking is to get rid of the dependency on
e_book_get_changes(). I already stopped using e_cal_get_changes()
because it was too inflexible.
Hello Suman!
I forgot to ask: do you agree in general with the plan to do atomic
updates via e_book_commit_contact() and e_cal_modify_object() by
defining the semantic as suggested?
I also need to extend the proposal: removing an item has similar race
conditions (sync starts, user updates item,
On Wed, 2009-01-07 at 12:45 +0100, Patrick Ohly wrote:
Hello!
I'm currently thinking about synchronizing data with SyncEvolution in
the background while the user is active with the Evolution UI. Some
users already do that via cron jobs, but it is known to be problematic
for several reasons,
On Thu, Jan 8, 2009 at 15:19, Patrick Ohly patrick.o...@gmx.de wrote:
The GroupWise server updates the 'modified' property of the item when
it actually gets modified on the server. For newly created items, it
also adds the 'created' property at the same time.
This behavior invalidates all the
Hello!
I'm currently thinking about synchronizing data with SyncEvolution in
the background while the user is active with the Evolution UI. Some
users already do that via cron jobs, but it is known to be problematic
for several reasons, among them change tracking and concurrent editing
of items.
Il giorno mer, 07/01/2009 alle 12.45 +0100, Patrick Ohly ha scritto:
Hello!
I'm currently thinking about synchronizing data with SyncEvolution in
the background while the user is active with the Evolution UI. Some
users already do that via cron jobs, but it is known to be problematic
for
On Wed, Jan 7, 2009 at 17:15, Patrick Ohly patrick.o...@gmx.de wrote:
The plan for change tracking is to get rid of the dependency on
e_book_get_changes(). I already stopped using e_cal_get_changes()
because it was too inflexible. Instead I'll rely on the REV resp.
LAST-MODIFIED properties:
