[Bug 25293] ChannelDispatcher: can't migrate channels between Clients

[bugzilla-daemon at freedesktop.org]

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

--- Comment #13 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-04-05 02:01:57 PDT ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > If I pass the empty string for the preferred handler, is it okay for MC to give
> > > me the channel right back again (if I'm the best match)?
> > 
> > I'd say no as the goal is explicitely to pass the channel to another client.
> > What do you think?
> 
> I agree. I think the method call should fail if the preferred handler doesn't
> exist, or if you pass "" and there are no handlers beside yourself.

Cool, that's already what the spec says (Not Capable error).

> > >     Additional information about the channels request, which will be used as
> > >     the value for the resulting request's Hints property.
> > > 
> > > What channel request? :)
> > 
> > Right. This move us back to the question "Should we allow to pass Hints" ?
> > If we want to (which is probably a good idea) and we don't create a
> > ChannelRequest (which I also think is a good idea) then our only option is to
> > add a 'Hints' (a(a{sv}) key to Handler_Info.
> 
> I don't really like this because it means that every implementation of
> HandleChannels() will have to look in two different places for hints. It won't
> be right by default.
> 
> I don't think making a ChannelRequest spring up would be so bad. It's a bit of
> an abuse, but…
> 
> I'm undecided about which I think would be worse.

I'm still not convinced we should have a ChannelRequest; that's a re-dispatch
request, not a channel one. And then, should DelegateChannels() return a CR
and the dispatching be delayed until we call CR.Proceed()?
If we don't, we have 2 different way to use CRs.

> > > ReEnsureChannel
> > > ---------------
> > > 
> > > Again, I think it would be better to have a different method name to more
> > > clearly signal the intent of this method. How about EvokeChannel()?
> > > EvokeHandlerForChannel()? KickHandler()? SummonHandler()?
> > 
> > PresentChannel()?
> 
> Someone got upset last time someone suggested “Present”—which is why I didn't
> suggest it—but given that this is what this method is *for* I think it's
> reasonable.

PresentChannel() it is then: changed.

> > > I think it's inconsistent that one of these methods can take hints and stuff,
> > > bu the other cannot. Since they both end up being a call to HandleChannels() on
> > > some handler…
> > 
> > If we go for the 'Hints' key in Handler_Info approach we can easily add one.
> 
> And if we go for “create a ChannelRequest”, then we can add one too. :)

Right.

So I think the last thing to decide is if we go for a CR or not.

Don't use CR
============

- Current approach in my branch/html file.
- Make things easier to use.
- The main (only) problem is how to pass the Hints to the Handler. Using
Handler_Info is handy but means we have 2 code paths to find Hints (sadface).

Use CR
======
- DelegateChannels() and PresentChannel() returns a CR.
- We have to change the description of ChannelRequel.
- Should user call CR.Proceed()?
- What would contain CR.Requests? The properties of the channel(s)?

-- 
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.