[Bug 46484] Add high-level Call bindings

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Mar 14 05:00:44 CET 2012


https://bugs.freedesktop.org/show_bug.cgi?id=46484

--- Comment #4 from George Kiagiadakis <kiagiadakis.george at gmail.com> 2012-03-14 04:00:44 UTC ---
(In reply to comment #2)
> - I don't get why you have several features which are basically getting all of
> the properties for the same interface. As long as Content makes some sense
> since it just pulls a single property, features CallState and CallMembers
> basically just do the same thing, just storing a different set of properties in
> the end. Given that the whole purpose of Features is to save DBus roundtrips,
> wouldn't it make more sense to merge at least State and Members together? (I'd
> be in favor of merging Contents as well, but there might be a use case for it)

FeatureContents should be a separate feature, since it also creates the
CallContent and CallStream objects with all their features.

FeatureCallMembers and FeatureCallState maybe... I separated them because they
are basically different things. You may want to know the state, but not the
members and vice versa. Members maintains internal hash tables with contacts
that might cost in memory/cpu if you have a lot of them, but other than that, I
guess the only other thing that prevents me from merging them is how to call
the combined feature :)

> 
> +            Q_ASSERT(mPriv->remoteMembersContacts.contains(handle));
> 
> I guess we don't want to assert here

Why not? It's a condition that should be met at this point. Saves us from
accidentally  creating a null ContactPtr without noticing (when calling
mPriv->remoteMembersContacts[handle] below).

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.



More information about the telepathy-bugs mailing list