[Bug 28200] TpBaseContactList

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed Jul 21 19:19:39 CEST 2010


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

--- Comment #35 from David Laban <david.laban at collabora.co.uk> 2010-07-21 10:19:39 PDT ---


> To do:
>
> The contactlist example CM isn't particularly realistic: it behaves as if
> incoming publish requests cause the contact to appear on our roster. It would
> be more realistic to have a separate list of requests, and have the Telepathy
> contact list be the union of the protocol roster and the requests list.
>
> Calling Unpublish() on a pending request would remove the contact from the
> requests list, and therefore from the Telepathy contact list (assuming we
> hadn't done anything that would cause them to be on our roster, like setting an
> alias or putting them in a group).

> Methods that create groups as a side-effect (like adding members to a
> nonexistent group) don't call the create_groups_async virtual method. I think
> that's OK - for robustness, the subclass ought to auto-create groups anyway -
> but would appreciate confirmation from reviewers.
I guess I'll have to try using it before I can really comment on this.
My initial thoughts are that on protocols where creating empty groups is a
no-op, calling create_groups_async() is just adding complication to the
bindings. Also, if tp-glib includes auto-create groups logic, it might be
expected to have auto-remove groups logic too, which is probably more difficult
to get right in a generic way?

> The create_groups_async virtual method and remove_group_async virtual methods
> are asymmetric (plural vs. singular). create_groups_async is never actually
> called except when CreateChannel or EnsureChannel is called for a GROUP
> ContactList channel, so we could make it singular.
>
> Alternatively, CreateChannel and EnsureChannel could call
> set_group_members_async(group, []) or add_to_group_async(group, []) (which the
> subclass has to support anyway, because they can be called from D-Bus),
> removing the need for an explicit create method.
Is the create method something that's going to disappear in telepathy-1.0 or
something? If so, avoiding it entirely sounds like the way forwards. Again, I
think implementing a CM or two and finding the edge cases is going to be more
useful than lots of discussion here.


In other news: Trivial things that made me have to think when reviewing your
code:
d979ef8b54643fecc0717467aa6a75db0c968809
+      GPtrArray *pa;
doesn't really tell me what you're about to do with it. s/pa/new_interfaces/ or
something? You use that variable name in a few places in base-contact-list.c,
but nowhere else in tp-glib.

Otherwise, contact-list-manager^^..contact-list-draft3 looks good. Will start
actually trying to use it tomorrow.

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



More information about the telepathy-bugs mailing list