[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 #8 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-07-12 05:27:39 PDT ---
(In reply to comment #6)
> (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.

Fair enough.

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

I agree, especially for the accept_invite case: why should user have to pass
his self TpContact to accept an invitation?

What's using this actually? Text for room invitations; StreamedMedia iirc,
Call? Maybe this should be part of the TpChannel subclass to properly watch
the exact semantic depending of the channel types?

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