Bug 40681 - TpConnection should prepare features on its self contact
Summary: TpConnection should prepare features on its self contact
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-glib (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://cgit.collabora.com/git/user/xc...
Whiteboard: review+
Keywords: patch
Depends on:
Blocks:
 
Reported: 2011-09-07 04:19 UTC by Xavier Claessens
Modified: 2011-09-12 04:07 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description Xavier Claessens 2011-09-07 04:19:22 UTC
TpConnection:self-contact should be guaranteed to always have factory features prepared. It is already part of TP_CONNECTION_FEATURE_CORE to fetch the self TpContact but with 0 feature. Nowadays it does not cost more to prepare all needed features with GetContactAttributes.
Comment 1 Xavier Claessens 2011-09-07 04:22:47 UTC
Here is proposed fix: http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=self-contact

It is a bit more complex than expected because we have to make sure the self contact is fetched late in connection's introspection so it has attribute ifaces.
Comment 2 Will Thompson 2011-09-07 04:30:35 UTC
(In reply to comment #1)
> It is a bit more complex than expected because we have to make sure the self
> contact is fetched late in connection's introspection so it has attribute
> ifaces.

Actually, you're allowed to blindly pass all the interfaces you want to GetContactAttributes() these days—but I guess tp-glib client side hasn't been updated to take advantage of that. (Or am I misunderstanding?)

http://telepathy.freedesktop.org/spec/Connection_Interface_Contacts.html#Method:GetContactAttributes

+  /* FIXME: We should use tp_simple_client_factory_dup_contact(), but that would

This function doesn't exist. (It is also mentioned in an existing comment in contact.c; perhaps you'd like to fix that at the same time.)

The branch looks fine, functionally speaking: perhaps a test case would be nice?
Comment 3 Xavier Claessens 2011-09-07 13:53:06 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > It is a bit more complex than expected because we have to make sure the self
> > contact is fetched late in connection's introspection so it has attribute
> > ifaces.
> 
> Actually, you're allowed to blindly pass all the interfaces you want to
> GetContactAttributes() these days—but I guess tp-glib client side hasn't been
> updated to take advantage of that. (Or am I misunderstanding?)

That would simplify stuff I guess. But atm in contacts_bind_to_signals() it ignore features wanted that does not have known interface.

Actually this make me realize a possible race with contact-list feature: if I get ContactListState going to SUCCESS before the TpConnection got its contact attribute interfaces, it won't prepare all features on roster contacts.

> +  /* FIXME: We should use tp_simple_client_factory_dup_contact(), but that
> would
> 
> This function doesn't exist. (It is also mentioned in an existing comment in
> contact.c; perhaps you'd like to fix that at the same time.)

fixed

> The branch looks fine, functionally speaking: perhaps a test case would be
> nice?

added


Branch updated
Comment 4 Will Thompson 2011-09-09 08:00:18 UTC
(In reply to comment #3)
> That would simplify stuff I guess. But atm in contacts_bind_to_signals() it
> ignore features wanted that does not have known interface.

Yeah, I don't think it needs changing before merging this branch.

> Actually this make me realize a possible race with contact-list feature: if I
> get ContactListState going to SUCCESS before the TpConnection got its contact
> attribute interfaces, it won't prepare all features on roster contacts.

This isn't a new issue introduced by this branch, right? Have you filed a bug for this?
Comment 5 Xavier Claessens 2011-09-12 03:57:44 UTC
thanks, merged.
Comment 6 Xavier Claessens 2011-09-12 04:07:42 UTC
(In reply to comment #4)
> (In reply to comment #3)
> > Actually this make me realize a possible race with contact-list feature: if I
> > get ContactListState going to SUCCESS before the TpConnection got its contact
> > attribute interfaces, it won't prepare all features on roster contacts.
> 
> This isn't a new issue introduced by this branch, right? Have you filed a bug
> for this?

That's not new, reported to bug #40797


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.