[Bug 43594] Add high-level API for ChannelDispatcher DelegateChannels/PresentChannel methods

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=43594

Olli Salli <olli.salli at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|ollisal at gmail.com           |olli.salli at collabora.co.uk

--- Comment #2 from Olli Salli <olli.salli at collabora.co.uk> 2012-07-06 04:59:51 PDT ---
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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.