GNOME Bugzilla – Bug 648805
Support lazy-loading contact attributes
Last modified: 2018-08-04 08:26:43 UTC
As described in bug #646808 comment #0, the Folks model of "load all contacts' attributes immediately" doesn't scale as well now that we've added a lot more types of attributes. To keep start-up load as light as possible, only Personas' linkable properties should be retrieved by default. This lets us guarantee that Personas will be linked into the same Individuals regardless of how many attributes have been retrieved. This coincides with the guarantee in bug #646808 that Individuals will have the same member Personas regardless of the search (though the values of non-searched attributes may vary depending on which attributes have been retrieved). As a general design point, the mechanism for specifying which attributes to fetch should be settable both before and after IndividualAggregator.prepare() and PersonaStore.prepare() are called. The use cases for the different set times: Before prepare: * clients know some non-linkable attributes they will always request (eg, Empathy requesting avatars), so this could let the PersonaStores avoid extra transitions (which might ripple into the UI). After prepare: * less-common UI components (eg, Empathy's "View Contacts on a Map" dialog) may need attributes that the common components don't (eg, geo-location) * some clients may wish to prioritize retrieving all Individuals (ie, "breadth-first" retrieval) to filling in those Individuals' details
Punting bugs that won't be fixed by Folks 0.6.0.
I'm updating folks to profit tp-glib's factory. It makes things much nicer since we can tell the factory which features we want in advance, and when we get the objects they are already prepared. What does it mean for this bug: 1) preparing (or upgrading) a contact when its added to roster before emitting change notification is racy. If a 2nd contact is prepared faster than the first, signal order can be inversed. TpConnection already deal with that by using a queue internally and it would be sad to add another queue in folks. So better rely on TpConnection to give us prepared contacts by setting features on the factory early. 2) nowadays getting the full contact list with all features is just 1 DBus call. So it's preferable to ask everything we want when fetching the roster than upgrading contacts later. DBus roundtrip is probably what takes most of the time. 3) Atm folks force having all features prepared, but only the user knows what feature the app really needs. So better let the user define features on the factory himself. 4) Adding features on the factory has no effect on already created TpContact. So if user already created contacts manually before calling aggregator.prepare(), we cannot easily prepare more features. Empathy actually does this. So all in all, I would depend on the app to define contact features itself and let it out of scope for folks. Note that this is a behaviour change, so if an existing app relied on folks to prepare the features it won't work anymore. Is that OK?
I've written code before which assumed that it can use Individual.full_name, .alias (fallback for full_name), .avatar, .email_address and .personas (as a work-around to get email addresses from Jabber contacts). Maybe it's safe to assume that full_name, alias, avatar and email_address are sensible defaults when nothing else is requested? Maybe that should be the default unless explicitly set to something else?
(In reply to comment #3) > I've written code before which assumed that it can use Individual.full_name, > .alias (fallback for full_name), .avatar, .email_address and .personas (as a > work-around to get email addresses from Jabber contacts). > Maybe it's safe to assume that full_name, alias, avatar and email_address are > sensible defaults when nothing else is requested? Maybe that should be the > default unless explicitly set to something else? To preserve existing behaviour, the default for lazy-loading has to be to load everything. The idea I (vaguely) had for this was to add a second constructor to Folks.IndividualAggregator which allows specifying which folks interfaces your program is (ever) going to use, and then only prepares features for them. The problem with this is the interaction with tp-glib's factory, which your program will have to prepare beforehand. If I've got everything correct, the solution (to this bug and partially implemented in Xavier's branch) is for your program to pass corresponding features to both tp-glib's factory and the IndividualAggregator constructor. Xavier, does that fit in with what you were thinking?
*** Bug 675131 has been marked as a duplicate of this bug. ***
-- 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/17.