http://bugzilla.moblin.org/show_bug.cgi?id=3479
--- Comment #9 from pohly <[email protected]> 2009-08-11 23:36:23 --- (In reply to comment #8) > After reading the eds-dbus code, I suspect "RETURN-REV" capability can't be > implemented for existing non-atomic calls. > > The reason is: the dbus call does not return "revision" or "Contact", the > changed item is asynchronously popped up by another signal > ("contacts-changed", > etc.). What's worse, the signal has a buffering mechanism, it will not emit as > soon as a contact is changed(maybe delayed to a later point to pop up a batch > of changes). > Two solutions: 1) change the dbus interface (incompatible) Isn't that interface EDS internal anyway and thus can be changed as necessary? Packagers must be sure to not put incompatible libebook and EDS on the same system, but that has always been the case. That packagers sometimes forgot about the necessary "conflicts" entries in their packages is a different problem... > For > the new added atomic calls, we can use a different dbus interface which will > return the "revision" information from the dbus method call. Using different communication paths with EDS to implement the old and new update/delete calls smells like unnecessary code duplication to me. I'd rather extend the protocol so that it works for the more advanced new calls and then map the old ones to the new ones in libebook (they are intentionally strict subsets). -- Configure bugmail: http://bugzilla.moblin.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching someone on the CC list of the bug. _______________________________________________ Syncevolution-issues mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution-issues
