I was just looking at that. The big question that I have here is where is the right place to add these methods. They do not depend on the account, therefore the Account class doesn't seem to be the right place. Another option would be AccountManager, but then this has nothing to do with accounts again. Another option would be Channel, but then it won't work if the channel was not requested by the CD. Any hints?

My 2 cents follow.

PresentChannel:

I'd say put it on the Channel object. It will work for ALL channels in the usual intended use cases of tp-qt (you're using the CD properly). (Requesting channels directly from the Connection requires using the #ifdefd advanced lowlevel API and is only applicable when you're the CD yourself).

This can be a straightforward wrapper using PendingVoid.

DelegateChannels:

Two important observations regarding this method:
 * Only a Handler for the channels in question can call this
 * After a successful call, the Handler needs to update its HandledChannels property

I think this makes AbstractClientHandler the perfect location for this API. You need to have one to be a Handler, and you need access to the ACH internals to do the HandledChannels update.

There's one drawback though: StreamTubeClient/Server hide the Handler behind the scenes. I don't think that's an issue though: tube channels only ever really Handleable by one client that supports that particular tube service. Hence there is little need for Delegating. If this proves to be a real problem, some pass-through method can be added easily enough to STC/STS.

Another instance where the Handler is hidden is when you're using the {ensure,create}AndHandle APIs. Then you'll get a HandledChannelNotifier from the  PendingChannel to use as a persistent token of still Handling the channel. I'd say put there a wrapper method which calls the ACH method with QList<ChannelPtr>(channel()) there.

Wherever we put this API, there needs to be some PendingOperation-derived job class which tells the ACH to update HandledChannels as needed, and offers access to the delegated and not delegated channel info. Both could point to the Channels with ChannelPtr - you can alternatively store the channel pointers when starting the operation from the arguments, or somehow dig up the ChannelFactory the ACH's ClientRegistrar is using, and use it to retrieve proxies for the channels. In either case, they're already prepared as per factory settings, as they've been handed to the application by the ClientRegistrar.

Implementation bonus points come if you avoid creating a ChannelDispatcherInterface for each operation somehow. Best would be if you could use the proxies from the DispatcherContext object the Account objects use internally.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-qt/issues/33.