Bug 69426

Also MediaSignalling, which is (unfortunately) mentioned in Handler.

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?

http://cgit.collabora.com/git/user/cassidy/telepathy-spec/log/?h=next-remove-sm

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

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

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

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

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

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.

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

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

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

Ship it!

Merged to next.