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 _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
