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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #11 from Guillaume Desmottes <guillaume.desmottes at collabora.co.uk> 2011-03-23 04:09:21 PDT ---
(In reply to comment #10)
> ReDispatchChannels
> ------------------
> 
> I think something like DelegateChannels() would be a better name. It doesn't
> actually send the channel through the whole dispatcher again—or does it? Do
> Observers get the channel again? Is a ChannelRequest created? I guess you think
> this is an open question too. :)

I'd say 'no' to all of these questions, so yeah DelegateChannels() sounds like
a better name. I renamed it.

> (In reply to comment #9)
> > Actually, what's the point to pass the Account to ReDispatchChannels() and
> > ReEnsureChannel()? MC should already know it from the channel(s).
> 
> I kind of agree. If ReDispatchChannels() is plural, then why shouldn't we be
> able to redispatch channels from different accounts? This would also make it
> marginally easier to use.

Ok, I removed the Account.

>     The time at which user action occurred, or 0 if this channel request is for
>     some reason not involving user action.
> 
> What channel request?

fixed.

>     Either the well-known bus name (starting with
>     org.freedesktop.Telepathy.Client.) of the preferred new handler for these
>     channels, or an empty string to indicate that any handler would be
>     acceptable. The behaviour and rationale are the same as for the
>     corresponding parameter to CreateChannelWithHints.
> 
> 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 think this method needs an example of how it would be used.

I'll add one once we agree on the API.

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

> 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()?

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

I updated:
http://git.collabora.co.uk/?p=user/cassidy/telepathy-spec;a=shortlog;h=refs/heads/re-handle-25293
http://people.freedesktop.org/~gdesmott/telepathy-spec-re_handle_25293/spec/Channel_Dispatcher.html#Method:DelegateChannels

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