[Bug 38801] Missing _async() wrappers for Channel.Group, Connection.ContactList and Connection.ContactGroups interfaces

[bugzilla-daemon at freedesktop.org]

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

--- Comment #6 from Will Thompson <will.thompson at collabora.co.uk> 2011-07-07 05:43:56 PDT ---
(In reply to comment #5)
> So the questions raised by Guillaume are basically:
> 
> 1) Do we want to keep multi-contact API, or only single-contac, or both? IMO
> most of the time only single-contact API is needed, and it could look nicer,
> but the multi-contact API is trivial to use with a single contact (1, &contact)
> and that could save several dbus roundtrips which is which is why we designed
> the spec like that. And having both is nice for the ContactList stuff because
> they are on tp_contact_foo_async() but for channel operations it isn't so nice
> to duplicate the methods...

I'm tempted to say “add both, where add_contact_async is a tiny tiny wrapper
around add_contactS_async” but I think that will clutter things.

Empathy, for instance, could well use the plural API for inviting contacts to a
group chat. Removing contacts could also conceivably be plural: select 5
contacts in the sidebar and mash a [remove] button at the bottom. So I think
reasonable applications may want the plural versions, so let's just have plural
versions, with clear examples in the docs for how to use them singularly in C.

> 2) Do we want both tp_channel_group_invite_async() and
> tp_channel_group_accept_async() methods doing the same thing, for nicer method
> names, or is it fine to keep tp_channel_group_add_members_async() which does
> both.

It's an implementation detail that they do the same thing on D-Bus. I assume
_accept_async() is for accepting other people's join requests, and there would
be an _accept_invitation_async() for accepting someone inviting us?

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