[Telepathy] tp-qt4 high level channel API sketch

[Simon McVittie]

I think Channel could benefit from having accessors for targetID(),
isRequested() and initiator() (a nullable Contact object) too.

Requested is a little tricky because it has to be a tri-state - on old
connection managers, we can't know whether the channel was requested or
not!

On Fri, 30 Jan 2009 at 11:37:47 -0300, Andre Moreira Magalhaes wrote:
> class GroupChannel : Channel:

Many channels are (at least potentially) a Group so I think this is
unnecessary - just fold it into the Channel class and have it not always
be relevant.

I think we agreed earlier that channels whose TargetHandleType is Contact
should fake being a Group with two members ("us" and "them"), even if at
the D-Bus level they're not.

The Group API should be based on Contact objects, not handles (at least
as a Feature, but probably as a core thing).

> signals:
>   void membersChanged(Contact[] current, Contact[] local, Contact[] remote);

This should resemble the new MembersChangedDetailed instead, and fake the
detailed signal from MembersChanged if necessary. (General principle:
make the C/C++ API look like the modern version of the D-Bus API rather
than the old version, wherever possible.)

It is very necessary to expose information about the change, like the actor
(who it was that made the change), reason, etc. - these are important
for chatrooms and StreamedMedia calls.

> class TextChannel : GroupChannel
> {
> public:
>   UintList allowedMessageTypes();
> 
>   PendingOperation *acknowledgePendingMessages(UintList messagesIds)
>   PendingMessages *pendingMessages();
>   PendingMessageToken *sendMessage(uint type, string message)

No, please leave TextChannel as a stub (no extra functionality over
Channel) for now, and design the Message sending and receiving as a separate
task, later. It's going to be a significant amount of work to construct a
good API (as opposed to a simple binding of the Text interface - anyone
who wanted that could just use the generated code).

When you do, the C++ API should be based on the combination of the Text and
Messages D-Bus interfaces, with a queue of Message objects that represent the
messages. (General principle, as above: Text can be viewed as a trivial
case of Text+Messages.)

> class ContactListChannel : GroupChannel
> {
> }

I don't think exposing the Contact List channels to library users is useful.
Adding "roster" functionality to Contact objects is already in the outline in
my "sketches" branch - that seems a much better API for the same thing.

    Simon