On Thu, 2012-12-06 at 10:43 -0500, Matthew Barnes wrote: > On Thu, 2012-12-06 at 16:22 +0100, Christian Hilberg wrote: > > * EClient starts transaction / acquires lock on PIM > > entry > > > > * E-D-S records transaction start / gives away the PIM > > entry lock to the EClient requesting > > > > * EClient dies for any reason > > > > * Started transaction / aquired PIM lock persists in > > E-D-S > > > > What now? Timeout after some time? Welcome back to possible > > raciness (-->does not truly solve our problem). > > This scenario is easily handled by watching the bus name of the client > process that acquired the lock. If the bus name vanishes, release the > lock immediately. > > But we have no such transaction lock at present, do we?
Hi, nope, there is no such API for it, and I do not think it's of any use when you consider the eds<->groupware server case. From my point of view the client should take care of the potential issues when modifying/removing the contact/event/.... When you look at it then the chain is: EClient <-> eds backend <-> remote server The EClient is a client for the eds backend. The eds backend is a client for the remote server. And you cannot expect remote servers running transaction locks on items when any client decides to take one. Evolution, as one of the EClient user, has capability of notifying user about received changes, at least the calendar part component editor notifies user when the item is opened and the view receives update of it. And that's the way to go. The connection between eds backend and remote server is harder, because the backend cannot talk to user directly right now, but I'm working on a service which will allow it, which should help too. Nonetheless, the conflict strategy is currently chosen by each respective backend coder, rather than left to a user. That said, I would not go with the "transaction locking", it doesn't fix much. I'd rather update book and calendar DBus/backend/EClient API to include necessary parameters for conflict resolution (enum for conflict resolution on modify and expected revision/last-modified for remove operations), and the client should implement what to do, if it gets Out-of-Sync error. The best if there is some centralized place for conflict resolution, thus the EClient users (and backends) will not need to duplicate the code. Though that's probably another question, and a project on its own. Bye, Milan _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers