http://bugzilla.moblin.org/show_bug.cgi?id=3479
--- Comment #9 from pohly <patrick.ohly(a)intel.com> 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.