GNOME Bugzilla – Bug 684764
too many FolksIndividual modification signals
Last modified: 2015-06-23 22:57:00 UTC
1. Create a contact in EDS: BEGIN:VCARD VERSION:3.0 FN:John Doe N:Doe;John END:VCARD 2. Subscribe to "notify" for that FolksIndividual. 3. Modify the contact in EDS: BEGIN:VCARD VERSION:3.0 FN:John Doe N:Doe;John BDAY:20120924 END:VCARD => 9 "notify" signals are triggered. This seems a bit excessive and causes unnecessary work in the consumer of the signal. It would be better to emit "notify" exactly once per change.
(In reply to comment #0) > => 9 "notify" signals are triggered. Can you find out exactly which properties are being notified? I suspect it will be the multi-valued properties (urls, email-addresses, phone-numbers, websites, groups, etc.), because they’ve been lazy-loaded. In order to save on memory allocations, folks’ EDS backend doesn’t load multi-valued property values until the user calls the getter method for that value. A side effect of this is that it can’t compare the old property value to the new one when the EContact is updated, so can’t know exactly which properties have been modified. It therefore has to overestimate the set of properties which have been changed, so emits more ‘notify’ signals than strictly necessary. If this is the case, it’s not actually a bug.
(In reply to comment #1) > (In reply to comment #0) > > => 9 "notify" signals are triggered. > > Can you find out exactly which properties are being notified? How would I do that, short of writing brute-force code which checks all properties for changes? > If this is the case, it’s not actually a bug. I agree, reducing the number of notifications is an enhancement request. Do you see a way to do that, for example with the freeze/thawn combination mentioned elsewhere?
Maybe related to bug #671636 ?
(In reply to comment #2) > How would I do that, short of writing brute-force code which checks all > properties for changes? Look at the ‘detail’ of the signal. You’ll have to connect to the detailed signal (e.g. “notify::email-addresses”) to do that. I can’t think of a way to connect to the normal signal (“notify”) and then extract the detail string from the callback, but there might be one. > > If this is the case, it’s not actually a bug. > > I agree, reducing the number of notifications is an enhancement request. Do you > see a way to do that, for example with the freeze/thawn combination mentioned > elsewhere? Well, if your code starts using the getters for the multi-valued properties, then folks will get hold of a copy of those properties in memory, and will be able to provide more accurate notifications. Folks’ EDS backend already uses [freeze|thaw]_notify() for contact modification notifications. [freeze|thaw]_notify() doesn’t reduce the number of ‘notify’ signal emissions (though it does squash duplicates together); it just ensures that they’re all emitted in the same cycle of the main loop. (In reply to comment #3) > Maybe related to bug #671636 ? Not really. This is about property modifications, whereas bug #671636 is about modifications to the set of Individuals. I don’t see any way to share a solution between them.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
(In reply to Philip Withnall from comment #4) > (In reply to comment #2) > > How would I do that, short of writing brute-force code which checks all > > properties for changes? > > Look at the ‘detail’ of the signal. You’ll have to connect to the detailed > signal (e.g. “notify::email-addresses”) to do that. I can’t think of a way > to connect to the normal signal (“notify”) and then extract the detail > string from the callback, but there might be one. For posterity: there is a way of doing this: call g_param_spec_get_name(pspec) on the pspec passed to the GObject::notify signal handler. That way, you can connect once to the un-detailed ::notify signal. Anyway, leaving this as INCOMPLETE.