GNOME Bugzilla – Bug 684766
Add signal for batches of property changes on Individuals
Last modified: 2018-08-04 08:34:47 UTC
For the PIM Manager D-Bus API (http://permalink.gmane.org/gmane.comp.mobile.syncevolution/4009) it would be useful if FolksIndividualAggregator told its user whether it has pending changes. The PIM Manager maps local signals to D-Bus signals. To reduce D-Bus traffic, it delays sending out changes immediately. But then it needs to know at which point it should flush the pending changes. Doing it each time FolksIndividualAggregator enters 'is-quiesent == True' state would be a good point. However, right now that only happens once. Later is-quiesent remains True even though changes from the underlying stores come in. As a workaround, PIM Manager now delays until the process is idle. But that is sub-optimal because there is no guarantee that all processing really happens before going idle. For example, it was observed that "notify" for a FolksIndividual was triggered several times (too often in fact, see bug #684764), then the idle callback was invoked, then another "notify" was triggered. Using a timeout also isn't nice because it adds unnecessary and undesirable latency.
The fix for this isn’t to change the behaviour of IndividualAggregator::is-quiescent, since that’s to do with whether Individuals (not their properties) have been enumerated for the first time. The fix is to add something like an Individual::properties-changed signal which is emitted once for each batch of property changes on an Individual. It would probably just be a pass-through of a Persona::properties-changed signal with identical behaviour. In EDS, for example, Eds.Persona.properties_changed would be emitted precisely when E.BookView.objects_mddified is emitted.
This isn't limited to modifying contacts. The same problem also exists for adding and removing contacts. (In reply to comment #1) > The fix for this isn’t to change the behaviour of > IndividualAggregator::is-quiescent, since that’s to do with whether Individuals > (not their properties) have been enumerated for the first time. > > The fix is to add something like an Individual::properties-changed signal which > is emitted once for each batch of property changes on an Individual. It would > probably just be a pass-through of a Persona::properties-changed signal with > identical behaviour. > > In EDS, for example, Eds.Persona.properties_changed would be emitted precisely > when E.BookView.objects_mddified is emitted. Do you mean "after the E.BookView.objects_modified signal was processed by libfolks"? That would help for modifications. For add or remove it is not enough, because EDS tends to send these changes in batches. I want to flush after all these batches were processed, not after each single one. EDS used to have a "sequence-complete" signal for this (http://developer.gnome.org/libebook/2.32/EBookView.html). The latest stable release mentions a "complete" signal which might be similar. Unfortunately it lacks documentation, so I'm not entirely sure.
(In reply to comment #2) > This isn't limited to modifying contacts. The same problem also exists for > adding and removing contacts. How so? As long as EDS is batching up additions/removals into a single objects_added and objects_removed signal emission, folks should already do the same and propagate that all the way through to result in just two emissions of IndividualAggregator::individuals-changed. > Do you mean "after the E.BookView.objects_modified signal was processed by > libfolks"? That would help for modifications. Yes. > For add or remove it is not enough, because EDS tends to send these changes in > batches. I want to flush after all these batches were processed, not after each > single one. > > EDS used to have a "sequence-complete" signal for this > (http://developer.gnome.org/libebook/2.32/EBookView.html). The latest stable > release mentions a "complete" signal which might be similar. Unfortunately it > lacks documentation, so I'm not entirely sure. That sounds icky to use. We already use the ‘complete’ signal when making our initial query to EDS, and it’s nasty. Can’t EDS be changed to batch up the changes even more or something? I’m not quite sure I understand the sequence of events here.
(In reply to comment #3) > (In reply to comment #2) > > This isn't limited to modifying contacts. The same problem also exists for > > adding and removing contacts. > > How so? As long as EDS is batching up additions/removals into a single > objects_added and objects_removed signal emission, I think it doesn't do that to avoid excessive message sizes. Consider the situation where 100 contacts were added in the EDS daemon (ignoring for a second how that was done). It would have to send a single message with 100 contacts. I believe it avoids that in favor of splitting into chucks with a certain maximum message size and/or number of contacts. That makes sense, because it allows to overlap generating and consuming these messages in a kind of streaming mode. > > For add or remove it is not enough, because EDS tends to send these changes in > > batches. I want to flush after all these batches were processed, not after each > > single one. > > > > EDS used to have a "sequence-complete" signal for this > > (http://developer.gnome.org/libebook/2.32/EBookView.html). The latest stable > > release mentions a "complete" signal which might be similar. Unfortunately it > > lacks documentation, so I'm not entirely sure. > > That sounds icky to use. We already use the ‘complete’ signal when making our > initial query to EDS, and it’s nasty. Can’t EDS be changed to batch up the > changes even more or something? I’m not quite sure I understand the sequence of > events here. What I'd like to see is this: - EDS sends multiple messages with new, modified or removed contacts. - libfolks processes those. - EDS emits "complete". - libfolks emits its own "complete" signal in the FolksIndividualAggregator. When pulling changes from a backend which doesn't have a "complete"-like signal, then emit "complete" whenever you are done with processing some change.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/folks/issues/43.