[Bug 28707] Clarify how to use hold/mute with Call

[bugzilla-daemon at freedesktop.org]

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

David Laban <david.laban at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |david.laban at collabora.co.uk

--- Comment #12 from David Laban <david.laban at collabora.co.uk> 2011-03-11 08:33:31 PST ---
> > > 1. Merge mute to Content and Call
> > There is already Content.Interface.Mute. Do you want it put into the main
> > Content interface or what? You want it duplicated in Call? Why?
> 
> We decided mute wasn't optional. The reason to duplicate it in Call is just to
> make it easier for applications.
> 
Okay. Thanks. Done. Note that I changed the wording of MuteState's docstring in
the same commit. Sorry. Please re-read it to make sure you agree.

> > > 3. Keep directions on Stream
> > Not sure what you mean here. Also: what do you want doing with
> > Call.Stream.RemoteMembers (map between contacts and their Sending State).
> 
> I meant that SetSending/RequestReceiving() would stay on the Stream Interface.
> 
Okay, so nothing to do here. Good Good.

> Mute != SendingStopped... with mute you could continue sending, but send
> silence. That's actually what your N900 does.
> 
Fixed. Thanks for clarifying.

> If you use the same enum for sending/receiving.. Rename Pending_SEnd... maybe
> to Pending_Flow ..
> 
Thanks for spotting that. Good catch.

> I'm not how how its not symmetrical ?
> 
See the top of your comment #5 regarding Hold. It seems that the only asymmetry
that seems to be reflected in the spec in its current form is that there is no
ReceivingMuted method. I will try to make sure that there is enough rationale
to explain the asymmetry before I merge, but I suppose it's not massively
important.

> > > Sending/ReceivingState properties on the stream ... with change notification
> > > with error
> > Hrrrm... Calling them the same thing on two different interfaces of the same
> > object. That's going to get confusing. TODO.
> 
> If you have a better idea.
I don't think that the UI really cares about the specific state of each
direction of each stream. It probably cares more whether the request for
mute/hold has actually been propagated to the media layer. I will take a look
at that next week. (TODO)

Note that the branch has been force-updated since you last looked. This is just
to rebase it on top of the current Call branch for my own sanity. The first
commit was not changed at all, and there were no conflicts.

http://git.collabora.co.uk/?p=user/alsuren/telepathy-spec.git;a=shortlog;h=refs/heads/mute

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