[Telepathy] Spec advice needed: ChannelDispatcher.DelegateChannels() and PresentChannel()

[Guillaume Desmottes]

Le mercredi 13 avril 2011 à 13:43 +0300, Olli Salli a écrit :
> On Wed, Apr 13, 2011 at 11:35 AM, Guillaume Desmottes
> <guillaume.desmottes at collabora.co.uk> wrote:
> > The other issue is about updating the Handler.HandledChannels property:
> > """
> > Humm I thought about a potential issue with DelegateChannels(). Handlers
> > are supposed to announce the channels they are handling in
> > Handler.HandledChannels
> > [1].
> >
> > In practice clients don't have to care as TpBaseClient (or the tp-qt4
> > equivalent) transparently does it for them. We'll have to make sure that
> > TpBaseClient is informed when a channel is delegated as it'll have to
> > remove the channel from the HandledChannels list.
> > Maybe we should announce that on D-Bus? Another option would be to hook
> > the tp-glib DelegateChannels API with TpBaseClient but that sounds
> > pretty fragile a bit hacky to me.
> >
> 
> Isn't only the Handler that's currently handling the channel supposed
> to call DelegateChannels on it? In this context, it'd make sense to me
> to make the DelegateChannels high-level API *a part of* whatever
> baseclass you derive from when being a Handler (AbstractClientHandler
> in tp-qt4, and I guess just the generic TpBaseClient in tp-glib?).
> Doing that, the API could sanity-check that the handler is in fact
> handling the channel in question (from the current value of
> HandledChannels) and update HandledChannels if the D-Bus call
> succeeds.


Indeed we could make it a TpBaseClient API even if that would be a bit
weird (a TpChannelDispatcher API would seem more natural imho). That
wouldn't help us if some does it behind our back (by using the D-Bus API
directly) but I'm ready to be convinced we don't care much about such
case.


	G.