Bug 52531

Summary:	Make possible to "upgrade" all proxies/contacts at once
Product:	Telepathy	Reporter:	Xavier Claessens <xclaesse>
Component:	tp-glib	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	CC:	xclaesse
Version:	unspecified	Keywords:	patch
Hardware:	Other
OS:	All
URL:	http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=prepare-all
Whiteboard:
i915 platform:		i915 features:
Attachments:	TpAccountManager: add _prepare_all_async() to prepare all proxies/contacts

Description Xavier Claessens 2012-07-26 11:09:30 UTC

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.

Comment 1 Xavier Claessens 2012-07-26 11:10:13 UTC

Created attachment 64718 [details] [review]
TpAccountManager: add _prepare_all_async() to prepare all proxies/contacts

This is convenient function for plugins and libraries.

Comment 2 Guillaume Desmottes 2012-07-30 08:33:19 UTC

Shouldn't the factory just prepare the new features when they are being added?

Comment 3 Xavier Claessens 2012-07-30 09:00:04 UTC

(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.

Comment 4 Xavier Claessens 2012-07-30 16:54:20 UTC

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

Comment 5 GitLab Migration User 2019-12-03 20:40:33 UTC

-- 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.