[Telepathy] tp-qt4 Requesting channels using ChannelDispatcher high-level API proposal

[Simon McVittie]

On Mon, 08 Jun 2009 at 17:40:05 -0300, Andre Moreira Magalhaes wrote:
>     bool canEnsureTextChannel();
>     ChannelRequestPtr ensureTextChat(

Looks good to me.

>     bool canEnsureGroupTextChat();
>     ChannelRequestPtr ensureGroupTextChat(
>             const QStringList &contactsIdentifiers,
>             QDateTime userActionTime = QDateTime::currentDateTime(),
>             const QString &preferredHandler = QString());

How would this work? By creating an empty group text chat (e.g. MSN
switchboard) and insta-inviting all those contacts? I think this is pretty
niche, so we should probably miss this one out (tbh, we can add it back in
later).

>     bool canEnsureRoomTextChat();
>     ChannelRequest *ensureRoomTextChat(

Looks good but I don't much like the naming. ensureChatroom()?
ensureTextChatroom()?

>     bool canEnsureMediaCall();
>     ChannelRequestPtr ensureMediaCall(

Can we make this ensureStreamedMediaCall so it's consistent with the name
of the class you'll get? (Or rename Tp::StreamedMediaCall to Tp::MediaCall,
but I'm not sure how wise that is)

>     bool canCreateFileTransfer();
>     ChannelRequestPtr createFileTransfer(

I don't think we should put this in until we have a better idea of which
parameters will be supported/required in more protocols.

Filename and Size are always mandatory, so if you're going to put this in the
header in #if 0, or on a branch, you should include those. Date is always
supported-but-optional, I think. ContentHashType and ContentHash may be
required in some protocols.

>     ChannelRequestPtr createChannel(
>             const QVariantMap &requestedProperties,
>             QDateTime userActionTime = QDateTime::currentDateTime(),
>             const QString &preferredHandler = QString());
>     ChannelRequestPtr ensureChannel(
>             const QVariantMap &requestedProperties,
>             QDateTime userActionTime = QDateTime::currentDateTime(),
>             const QString &preferredHandler = QString());

Yes, we need these.

> Now aditional contact methods, some would require ContactCapabilities 
> support.

ContactCapabilities are still draft, so do not implement these now.

>     ChannelRequestPtr ensureTextChat(
>             QDateTime userActionTime = QDateTime::currentDateTime(),
>             const QString &preferredHandler = QString());
>
> * Note that Contact object would have to have access to the Contact 
> Account object,
> which is not always possible (e.g: not using AccountManager), so the Contact
> methods would only work when an Account is being used.

This is quite nasty. Let's just support the normal way to do it (methods on
the Account) at least for now. Once that's implemented and merged, if you have
some good ideas for how to make this mechanism not be a land mine in people's
code, you can suggest them too.

> * Should we support Tubes, FileTransfer here, as the support for them is 
> not complete yet?

No. File Transfer has an assortment of additional properties, some of which
are not always required; Tubes are also pretty complex. To be honest, anyone
who's using either of these at this stage in development should be able to get
by with the lower-level (QVariantMap) API.

    Simon