Re: [Evolution-hackers] Funambol sync from evolution
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
Re: [Evolution-hackers] Funambol sync from evolution
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] concurrent modifications of items in GUI and EDS database
On Thu, Jan 8, 2009 at 15:19, Patrick Ohly 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
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] Funambol sync from evolution
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] concurrent modifications of items in GUI and EDS database
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 > > T
Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database
On Thu, 2009-01-08 at 10:49 +0100, Patrick Ohly wrote: > On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote: > > On Wed, Jan 7, 2009 at 17:15, Patrick Ohly 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. As suman had mentioned, this is not a problem for calendar as the modifications are notified to the UI by matching the live queries in place. > > > > 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 appoi
Re: [Evolution-hackers] concurrent modifications of items in GUI and EDS database
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] Cannot run evolution built using jhbuild
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
On Thu, 2009-01-08 at 10:10 +0530, Suman Manjunath wrote: > On Wed, Jan 7, 2009 at 17:15, Patrick Ohly 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
