Bug 69426

Summary: [1.0] expunge mentions of StreamedMedia
Product: Telepathy Reporter: Simon McVittie <smcv>
Component: tp-specAssignee: Telepathy bugs list <telepathy-bugs>
Status: RESOLVED FIXED QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium Keywords: patch
Version: git master   
Hardware: Other   
OS: All   
URL: http://cgit.collabora.com/git/user/cassidy/telepathy-spec/log/?h=next-remove-sm
Whiteboard:
i915 platform: i915 features:

Description Simon McVittie 2013-09-16 16:09:50 UTC
+          <p>If a one-to-one StreamedMedia call fails because the
+            contact being called is busy, the connection manager
+            SHOULD indicate this by removing both the

... no, we have Call1.
Comment 1 Simon McVittie 2013-09-16 16:18:47 UTC
Also MediaSignalling, which is (unfortunately) mentioned in Handler.
Comment 2 Guillaume Desmottes 2014-02-07 11:07:51 UTC
In Call1:
"""
      <p>A channel type for making audio and video calls. Call channels
        supersede the old StreamedMedia channel type. Call channels
        are much more flexible than its predecessor and allow more
        than two participants.</p>
""""

Do you want to remove this and pretend StreamedMedia never existed or do you prefer to keep it as it?
Comment 4 Simon McVittie 2014-02-07 11:31:09 UTC
(In reply to comment #2)
> In Call1:
> """
>       <p>A channel type for making audio and video calls. Call channels
>         supersede the old StreamedMedia channel type. Call channels
>         are much more flexible than its predecessor and allow more
>         than two participants.</p>
> """"
> 
> Do you want to remove this and pretend StreamedMedia never existed or do you
> prefer to keep it as it?

That instance is fine to keep.
Comment 5 Simon McVittie 2014-02-07 11:37:45 UTC
- <p>If a one-to-one StreamedMedia call fails because the
- contact being called is offline, the connection manager
- SHOULD indicate this by removing both the
- <tp:member-ref>SelfHandle</tp:member-ref> and the other
- contact's handle from the Group interface with reason
- Offline.</p>
-
- <tp:rationale>
- For 1-1 calls, the call terminates as a result of removing the
- remote contact, so the SelfHandle should be removed at the same
- time as the remote contact and for the same reason.
- </tp:rationale>

Does the Offline group-change reason still make sense? I suppose we could represent IRC QUIT as leaving for reason Offline, and IRC PART as leaving for reason None.
Comment 6 Simon McVittie 2014-02-07 11:40:12 UTC
> <p>The change is due to a busy indication.</p>
> - <p>If a one-to-one StreamedMedia call fails because the
> - contact being called is busy, the connection manager

Can this happen in circumstances other than a call? I suppose a group invitation could conceivably fail with "busy" in some hypothetical protocol...

<tp:docstring xmlns="http://www.w3.org/1999/xhtml">
<p>The change is because the requested contact does not exist.</p>
- <p>For instance, if the user invites a nonexistent contact to a
- chatroom or attempts to call a nonexistent contact, this could
- be indicated by the CM adding that contact's handle to
- remote-pending for reason None or Invited, then removing it for
- reason Invalid_Contact. In the case of a 1-1 StreamedMedia
- call, the CM SHOULD remove the self handle from the Group
- in the same signal.</p>
-
- <tp:rationale>
- For 1-1 calls, the call terminates as a result of removing the
- remote contact, so the SelfHandle should be removed at the same
- time as the remote contact and for the same reason.
- </tp:rationale>

Please keep part of that first deleted paragraph:

    <p>For instance, if the user invites a nonexistent contact to a
      chatroom, this could be indicated by the CM adding that
      contact's handle to remote-pending for reason None or Invited,
      then removing it for reason Invalid_Contact.</p>
Comment 7 Simon McVittie 2014-02-07 11:46:30 UTC
- <tp:rationale>
- <p>An equivalent of the gtalk-p2p-relay-token property on
- MediaSignalling channels is not included here. The connection
- manager should be responsible for making the necessary HTTP
- requests to turn the token into a username and password.</p>
- </tp:rationale>

I don't think this needs to be deleted: it's comparison with an obsoleted API, explaining why we changed it. Rationale > no rationale.

If you want to re-word it, it could be something like:

  <tp:rationale>
    <p>Unlike the MediaSignalling API in older versions of Telepathy,
      this does not include protocol-specific authentication tokens
      such as the &lt;relay&gt;&lt;token/&gt;&lt;/relay&gt;
      construct used by Google Talk; the connection manager should be
      responsible for making any necessary service-specific requests
      to turn the token into a username and password.</p>
  </tp:rationale>
Comment 8 Guillaume Desmottes 2014-02-07 11:46:52 UTC
(In reply to comment #5)
> Does the Offline group-change reason still make sense? I suppose we could
> represent IRC QUIT as leaving for reason Offline, and IRC PART as leaving
> for reason None.

Isn't what's implemented in idle already? See idle_muc_channel_quit() and idle_muc_channel_part()
Comment 9 Simon McVittie 2014-02-07 11:48:17 UTC
Looks good, other than Comment #6 and Comment #7.

If there are any group change reasons that made sense for StreamedMedia calls but make no sense whatsoever for chatrooms, this would be a good time to delete them.
Comment 10 Simon McVittie 2014-02-07 11:49:43 UTC
(In reply to comment #8)
> Isn't what's implemented in idle already?

Yes. Objection withdrawn :-)

BUSY is OK to keep as well, if you think it might ever be used for chatrooms.
Comment 11 Guillaume Desmottes 2014-02-07 13:21:02 UTC
(In reply to comment #6)
> Please keep part of that first deleted paragraph:
> 
>     <p>For instance, if the user invites a nonexistent contact to a
>       chatroom, this could be indicated by the CM adding that
>       contact's handle to remote-pending for reason None or Invited,
>       then removing it for reason Invalid_Contact.</p>

Done.

(In reply to comment #7)
> - <tp:rationale>
> - <p>An equivalent of the gtalk-p2p-relay-token property on
> - MediaSignalling channels is not included here. The connection
> - manager should be responsible for making the necessary HTTP
> - requests to turn the token into a username and password.</p>
> - </tp:rationale>
> 
> I don't think this needs to be deleted: it's comparison with an obsoleted
> API, explaining why we changed it. Rationale > no rationale.
> 
> If you want to re-word it, it could be something like:
> 
>   <tp:rationale>
>     <p>Unlike the MediaSignalling API in older versions of Telepathy,
>       this does not include protocol-specific authentication tokens
>       such as the &lt;relay&gt;&lt;token/&gt;&lt;/relay&gt;
>       construct used by Google Talk; the connection manager should be
>       responsible for making any necessary service-specific requests
>       to turn the token into a username and password.</p>
>   </tp:rationale>

Done.

The branch has been updated.
Comment 12 Guillaume Desmottes 2014-02-07 13:22:46 UTC
(In reply to comment #9)
> Looks good, other than Comment #6 and Comment #7.
> 
> If there are any group change reasons that made sense for StreamedMedia
> calls but make no sense whatsoever for chatrooms, this would be a good time
> to delete them.

Don't think so. Even 'No_Answer' could be used on some protocol where invitations can time out.
Comment 13 Simon McVittie 2014-02-07 14:00:57 UTC
Ship it!
Comment 14 Guillaume Desmottes 2014-02-07 14:13:53 UTC
Merged to next.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.