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

[Andre Moreira Magalhaes]

Simon McVittie wrote:
> 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).
>
>   
Yeah, this was a helper method, it would create a text chat and add 
other contacts to it, but yes, this is not needed.

>>     bool canEnsureRoomTextChat();
>>     ChannelRequest *ensureRoomTextChat(
>>     
>
> Looks good but I don't much like the naming. ensureChatroom()?
> ensureTextChatroom()?
>
>   
I was trying to use the same nomenclature for all methods, but yes, it 
wasn't good :P

I liked 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)
>
>   
See below
>>     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.
>
>   
Indeed, I will remove this for now
>>     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.
>
>   
Ok
>>     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.
>
>   
Ok
>> * 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.
>
>   
Good, so that makes my life easier :)

Question, naming:
- Should we call this ensureTextChat or ensureTextChannel, 
ensureStreamedMediaChannel or ensureStreamedMediaCall?
I prefer Chat and Call.

BR
Andre