Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Patrick Ohly
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. Instead I'll rely on the REV resp.
  LAST-MODIFIED properties: the backend must update these each time an
  item is modified. This seems to be supported by most backends. Are there
  backends which are known to not support this?
 
 a) Looking at [1], I can't find what a REV property is. Did you mean
 to use [2] ?

REV is part of vCard 3.0. It would be used in ebook. ecal would use
LAST-MODIFIED instead. Does the GroupWise server update REV when
contacts are modified?

  The problem with concurrent modifications is two-fold.
  Stale data in UI:
   * user opens an item in Evolution
   * synchronization starts in the background
   * updates the item in EDS
   * = When the user saves his changes, will he overwrite the more
 recent data in EDS? Will he be warned? With Evolution the user
 is not warned and his changes overwrite the ones in EDS (tested
 with contacts). Evolution should listen for change signals and
 warn the user as soon as he has stale data in the edit dialog.
 The user then can cancel and reopen the item to redo his
 changes. This is unlikely to happen often, so more elaborate
 solutions (merging changes, additional buttons to copy from EDS)
 should not be necessary. Should I file a bug for this? Anyone
 able and willing to work on it?
 
 Not so for calendars.

I only tested with a contact. There the problem occurs as described
above.

  Stale data in sync:
   * when the sync starts, it builds a list of new/updated/deleted
 items
   * user modifies data in EDS
   * this leads to conflicts, f.i. sync modifies item that was
 modified by user
 
  Both cases need to be handled by the program which wants to make changes
  to EDS data (Evolution, sync engine). To avoid race conditions, support
  by EDS would be needed which currently doesn't exist. As a workaround
  the following method would reduce the time window in which conflicts can
  occur:
   * get revstring before starting to make modifications (when
 opening item in UI; when starting sync)
   * before modifying the item, check the revstring again
   * if the same as before, do the modification
   * if different, handle conflict
 
 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 'handle-at-backend' approaches to
 fix the apparent bug,

the apparent bug =
https://bugzilla.novell.com/show_bug.cgi?id=184554 ?

Or do you mean the problem with overwriting more recent changes?

I'm not sure I understood how the GroupWise server and backend work.
What you are saying is that locally cached data might get out of sync
with the server and thus checks in the Evolution backend cannot be
implemented 100% accurately, right?

That sounds like a real problem, but I still see room for improvement.
For example, the backend could implement the workaround that I described
in my email. A client can't do that because without changes in the
backend it might read stale data, compare successfully, then push an
update which overwrites modifications on the server.

  A secure solution would have to put the revision check into EDS itself
  to make the check and update atomic. The proposal is to add this check
  to e_book_commit_contact() and e_cal_modify_object():
   * The caller is expected to include REV resp. LAST-MODIFIED as
 read from EDS earlier.
   * The EDS backend compares against the current value before
 updating the item. If there is a mismatch, the update is
 rejected with a suitable error code.
   * If the values are unset, the update is always executed.
 
 A backend may not have a LAST-MODIFIED property for a particular event
 in this use case:
 a) create a new appointment in the GW calendar (while online)
 b) open the same appointment (before the refresh timeout)

That's because the local copy of the appointment is not identical to the
one on the server, right? Perhaps the backend could force an immediate
refresh of this particular appointment to get the server's
LAST-MODIFIED?

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Cannot run evolution built using jhbuild

2009-01-08 Thread Stefano Canepa
Il giorno gio, 08/01/2009 alle 00.10 +0100, Tobias Mueller ha scritto:
 Hi,
 
 On 07.01.2009 22:20, Stefano Canepa wrote:
  2) what's going wrong the evolution built by jhbuild?
  
 The build itself works properly, right? Running your newly build
 Evolution fails, if I read your log correctly.
 

Thanks for your help. You got it.

Bye
sc

PS: I'm subscribed to the list so do not email me directly CC-ing the
list my filters get confused. Thanks

-- 
Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virtù di un programmatore: pigrizia, impazienza e
arroganza. (Larry Wall)


signature.asc
Description: Questa è una parte del messaggio	firmata digitalmente
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Patrick Ohly
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, sync removes item). The
current APIs for removing items make it harder to pass in the expected
REV resp. LAST-MODIFIED. The only API call that could do it without
changing its prototype is e_book_async_remove_contact(EContact
*contact). e_book_remove_contact(), e_cal_remove_object(),
e_cal_remove_object_with_mod() all just take ID strings.

When e_cal_remove*() refers to multiple VEVENTs it might also be
difficult to specify the expected LAST-MODIFIED of each VEVENT. I don't
have a good solution for the remove case. New API calls?

e_cal_modify_object() has the same problem with multiple VEVENTs, but
this can be solved: for CALOBJ_MOD_THIS[ANDPRIOR|FUTURE], the
LAST-MODIFIED property of the referenced VEVENT is to be compared. For
CALOBJ_MOD_ALL the main event is checked.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Chenthill
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, among them change tracking and concurrent editing
 of items.
 
 I already discussed this with Ross Burton and Rob Bradford. Now I would
 like to check that we haven't missed anything.
 
 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: the backend must update these each time an
 item is modified. This seems to be supported by most backends. Are there
 backends which are known to not support this?
 
 REV and LAST-MODIFIED are treated as opaque revision strings.
 SyncEvolution doesn't interpret the content, only compares it against
 the last synchronized value.
For calendar, we just use last modified time.

 
 The problem with concurrent modifications is two-fold.
 Stale data in UI:
   * user opens an item in Evolution
   * synchronization starts in the background
   * updates the item in EDS
   * = When the user saves his changes, will he overwrite the more
 recent data in EDS? Will he be warned? With Evolution the user
 is not warned and his changes overwrite the ones in EDS (tested
 with contacts). Evolution should listen for change signals and
 warn the user as soon as he has stale data in the edit dialog.
 The user then can cancel and reopen the item to redo his
 changes. This is unlikely to happen often, so more elaborate
 solutions (merging changes, additional buttons to copy from EDS)
 should not be necessary. Should I file a bug for this? Anyone
 able and willing to work on it?
 
 Stale data in sync:
   * when the sync starts, it builds a list of new/updated/deleted
 items
   * user modifies data in EDS
   * this leads to conflicts, f.i. sync modifies item that was
 modified by user
In both cases EDS signals modification of event to UI and all the
clients listening on the ECalView.. The clients need to watch for this
signal and update them accordingly.

 
 Both cases need to be handled by the program which wants to make changes
 to EDS data (Evolution, sync engine). To avoid race conditions, support
 by EDS would be needed which currently doesn't exist. As a workaround
 the following method would reduce the time window in which conflicts can
 occur:
   * get revstring before starting to make modifications (when
 opening item in UI; when starting sync)
   * before modifying the item, check the revstring again
   * if the same as before, do the modification
   * if different, handle conflict 
 
 A secure solution would have to put the revision check into EDS itself
 to make the check and update atomic. The proposal is to add this check
 to e_book_commit_contact() and e_cal_modify_object():
   * The caller is expected to include REV resp. LAST-MODIFIED as
 read from EDS earlier.
   * The EDS backend compares against the current value before
 updating the item. If there is a mismatch, the update is
 rejected with a suitable error code.
   * If the values are unset, the update is always executed.
 
 Problem 1: a client cannot tell whether the backend that it is using
 implements this check. If the backend doesn't (not yet updated, not
 possible), then the client should implement the workaround described
 above.
Since the backends emit the notification, currently it assumed that the
clients would handle it. I don think the backends check for the last
modified time while updating... I think it should be handled both at the
client side as well as EDS side to avoid race conditions.

 
 Problem 2: the backend cannot tell whether the client wants to have the
 check enabled or not. An older client might send values for
 REV/LAST-MODIFIED and might expect to always succeed. Such a client
 could be considered broken and refusing the update might be the right
 solution.
 
 Problem 3: the Exchange Connector does not update LAST-MODIFIED if the
 VEVENT contains it. I consider this a bug and work around it in
 SyncEvolution by filtering out the property before importing into EDS.
 Adding LAST-MODIFIED unconditionally would break change tracking.
This should be a bug if exchange is not updating the last-modified time.

 
 Exact handling of REV and LAST-MODIFIED in the two calls is basically
 undefined right now as far as I can tell. I suggest to clarify that:
   * backends should check them as described above
   * backends must update them independently of what the client sends
 
 To allow clients to query whether the backend supports the check I
 suggest to add a new 

Re: [Evolution-hackers] Funambol sync from evolution

2009-01-08 Thread Stefano Canepa
On Wed, 2009-01-07 at 20:22 -0800, George Farris wrote:
 On Wed, 2009-01-07 at 23:20 +0100, Patrick Ohly wrote:
  My suggestion regarding the language would be to check out how easy it
  is to write Evolution plugins in C and Python. Pick the one that you
  find easier. Python is a nice language. A downside might be that users
  of older Evolution releases without that support won't be able to use
  your plugin. When was Python support added?
  
 
 Maybe have a look at Vala 
 
 http://live.gnome.org/Vala
 
 Kind of best of both worlds, Python/ C
 
 Cheers

So you suggest to learn another language? ;-)

Bye
sc

-- 
Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virtù di un programmatore: pigrizia, impazienza e
arroganza. (Larry Wall)


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Funambol sync from evolution

2009-01-08 Thread Stefano Canepa
On Wed, 2009-01-07 at 23:20 +0100, Patrick Ohly wrote:
  On user request the plugin will run syncevolution,
  displaing an error message if there is no syncevolution on the
 system
  and the log and all messages of syncevolution if there are logs or
  messages.
 
 It wouldn't be hard to create and install a libsyncevolution.so which
 contains all the necessary logic to execute a sync. That might be
 easier
 than wrapping a command line tool. On the other hand, Genesis already
 does that quite successfully.

OK, Patric. I'll checkout syncevolution code ASAP (tomorrow or on
saturday) and starting finding how I to build such a library, this
should be usefull for other projects, too.

Bye
sc

-- 
Stefano Canepa aka sc: s...@linux.it - http://www.stefanocanepa.it
Three great virtues of a programmer: laziness, impatience and hubris.
Le tre grandi virtù di un programmatore: pigrizia, impazienza e
arroganza. (Larry Wall)


signature.asc
Description: This is a digitally signed message part
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database

2009-01-08 Thread Suman Manjunath
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 'handle-at-backend' approaches to
 fix the apparent bug,

 the apparent bug =
 https://bugzilla.novell.com/show_bug.cgi?id=184554 ?

Yep.. it is this ^^ bug. And I agree with Chen that it needs a fix at
the backend.

-Suman
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Funambol sync from evolution

2009-01-08 Thread George Farris
On Thu, 2009-01-08 at 23:03 +0100, Stefano Canepa wrote:
 On Wed, 2009-01-07 at 20:22 -0800, George Farris wrote:
  On Wed, 2009-01-07 at 23:20 +0100, Patrick Ohly wrote:
   My suggestion regarding the language would be to check out how easy it
   is to write Evolution plugins in C and Python. Pick the one that you
   find easier. Python is a nice language. A downside might be that users
   of older Evolution releases without that support won't be able to use
   your plugin. When was Python support added?
   
  
  Maybe have a look at Vala 
  
  http://live.gnome.org/Vala
  
  Kind of best of both worlds, Python/ C
  
  Cheers
 
 So you suggest to learn another language? ;-)
 

Sure why not, it's always good for the brain:-)



___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Funambol sync from evolution

2009-01-08 Thread Patrick Ohly
On Fri, 2009-01-09 at 00:00 +0100, Stefano Canepa wrote:
 On Wed, 2009-01-07 at 23:20 +0100, Patrick Ohly wrote:
  It wouldn't be hard to create and install a libsyncevolution.so which
  contains all the necessary logic to execute a sync. That might be
  easier
  than wrapping a command line tool. On the other hand, Genesis already
  does that quite successfully.
 
 OK, Patric. I'll checkout syncevolution code ASAP (tomorrow or on
 saturday) and starting finding how I to build such a library, this
 should be usefull for other projects, too.

I should clarify: compiling and installing libsyncevolution.so already
works, just use --enable-shared. However, there are some issues with it:
  * It's an internal helper library installed as
lib/syncevolution/libsyncevolution.so.0.0.0, making linking
against it harder.
  * It is unversioned (ABI can change without updating the so
number). Other packages are not supposed to link against it
right now.
  * Making the plugin a part of SyncEvolution would avoid these
issues, but that leads to another problem for distributing it:
currently the precompiled packages are constructed so that they
don't depend on a specific Evolution version (search for
multiple revisions of libecal/libebook, call functions via
dlsym). This might not be feasible with a plugin, so that I'd
have to go back to compiling different packages for different
Evolution releases - or depend on distributions to do that work.

But that is something that we can worry about later - let's get
something working first, shall we? ;-)

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/

___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers