When adding features on the factory using tp_client_factory_add_*_features() it won't get prepared on already existing proxies. For applications controlling the AM's creation that's not an issue because it can set all required features before preparing the AM. But for plugins/libraries, when they do tp_a_m_dup() they cannot know if accounts/connections/contacts objects already exists. And if the library (e.g. Folks) wants to add features on the factory that won't apply on already existing objects. So I suggest tp_a_m_prepare_all_async() that will prepare all proxies/contacts known to the am's factory with latest features set on it.
Created attachment 64718 [details] [review] TpAccountManager: add _prepare_all_async() to prepare all proxies/contacts This is convenient function for plugins and libraries.
Shouldn't the factory just prepare the new features when they are being added?
(In reply to comment #2) > Shouldn't the factory just prepare the new features when they are being added? _add_*_features() are not async, so it can't be done, or at least you can't know when it will be done preparing.
Ok, one good argument against this: <oggis> why I originally chose against this kind of stuff is the following kind of scenario: 1) something sees a new service object it wants to proxy, say AM sees an Account 2) it asks for the proxy from the factory, that becomes a pending operation which completes once the features requested by then are there 3) somebody pokes the factory to add more features 4) the original prepare with less features completes - without complex hacks, this'd cause the AM to signal the account as being there but that's "wrong" - the newly requested features are not there of course, whatever poked the factory to add more features is probably waiting for that new "reprepare" operation to finish - which does when the newly requested features are there too but it sounds very easy to mess up the event handling, when you are waiting for your "reprepare" to finish, but simultaneously can receive events for new proxies with the "old" features
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org'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.freedesktop.org/telepathy/telepathy-glib/issues/100.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.