<commit_before><?xml version="1.0" ?>
<node name="/Channel_Type_Streamed_Media_Future"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright> Copyright © 2009 Collabora Limited </tp:copyright>
  <tp:copyright> Copyright © 2009 Nokia Corporation </tp:copyright>
  <tp:license xmlns="http://www.w3.org/1999/xhtml">
    <p>This library is free software; you can redistribute it and/or
      modify it under the terms of the GNU Lesser General Public
      License as published by the Free Software Foundation; either
      version 2.1 of the License, or (at your option) any later version.</p>

    <p>This library is distributed in the hope that it will be useful,
      but WITHOUT ANY WARRANTY; without even the implied warranty of
      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
      Lesser General Public License for more details.</p>

    <p>You should have received a copy of the GNU Lesser General Public
      License along with this library; if not, write to the Free Software
      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
      USA.</p>
  </tp:license>
  <interface name="org.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTURE">
    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      <p>This interface contains functionality which we intend to incorporate
        into the <tp:dbus-ref
          namespace="org.freedesktop.Telepathy">Channel.Type.StreamedMedia</tp:dbus-ref>
        interface in future. It should be considered to be conceptually part
        of the core StreamedMedia interface, but without API or ABI
        guarantees.</p>

      <tp:rationale>
        <p>The rationale is the same as for <tp:dbus-ref
            namespace="org.freedesktop.Telepathy">Channel.FUTURE</tp:dbus-ref>.</p>
      </tp:rationale>
    </tp:docstring>

    <property name="InitialAudio" tp:name-for-bindings="Initial_Audio"
      type="b" access="read">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>If set to true in a channel request that will create a new channel,
          the connection manager should immediately attempt to establish an
          audio stream to the remote contact, making it unnecessary for the
          client to call <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">RequestStreams</tp:dbus-ref>.</p>

        <p>If this property, or InitialVideo, is passed to EnsureChannel
          (as opposed to CreateChannel), the connection manager SHOULD ignore
          these properties when checking whether it can return an existing
          channel as suitable; these properties only become significant when
          the connection manager has decided to create a new channel.</p>

        <p>If true on a requested channel, this indicates that the audio
          stream has already been requested and the client does not need to
          call RequestStreams, although it MAY still do so.</p>

        <p>If true on an unrequested (incoming) channel, this indicates that
          the remote contact initially requested an audio stream; this does
          not imply that that audio stream is still active (as indicated by
          <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">ListStreams</tp:dbus-ref>).</p>

        <p>This property is immutable (cannot change), and therefore SHOULD
          appear wherever immutable properties are reported, e.g. <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
          signals.</p>

        <tp:rationale><p>This reduces D-Bus round trips.</p></tp:rationale>

        <p>Connection managers capable of signalling audio calls to contacts
          SHOULD include a channel class in <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
          with <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>
          = <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
          and <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
          = Contact in the fixed properties dictionary, and InitialAudio
          (and also InitialVideo, if applicable) in the allowed properties
          list. Clients wishing to discover whether a connection manager
          can signal audio and/or video calls SHOULD use this information.</p>

        <tp:rationale>
          <p>Not all protocols support signalling video calls, and it would be
            possible (although unlikely) to have a protocol where only video,
            and not audio, could be signalled.</p>
        </tp:rationale>

        <p>Connection managers that support the <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities.DRAFT</tp:dbus-ref>
          interface SHOULD represent the capabilities of receiving audio
          and/or video calls by including a channel class in
          a contact's capabilities with ChannelType = StreamedMedia
          in the fixed properties dictionary, and InitialAudio and/or
          InitialVideo in the allowed properties list. Clients wishing to
          discover whether a particular contact is likely to be able to
          receive audio and/or video calls SHOULD use this information.</p>

        <tp:rationale>
          <p>Not all clients support video calls, and it would also be
            possible (although unlikely) to have a client which could only
            stream video, not audio.</p>
        </tp:rationale>

        <p>Clients that are willing to receive audio and/or video calls
          SHOULD include the following filters if calling <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
          (clients of a <tp:dbus-ref
            namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</tp:dbus-ref>
          SHOULD instead arrange for the ChannelDispatcher to do this,
          by including the filters in their <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandlerChannelFilter</tp:dbus-ref>
          properties):</p>

        <ul>
          <li>{ ChannelType = StreamedMedia }</li>
          <li>{ ChannelType = StreamedMedia, InitialAudio = true }
            if receiving calls with audio is supported</li>
          <li>{ ChannelType = StreamedMedia, InitialVideo = true }
            if receiving calls with video is supported</li>
        </ul>

        <tp:rationale>
          <p>Connection managers for protocols with capability discovery,
            like XMPP, need this information to advertise the appropriate
            capabilities for their protocol.</p>
        </tp:rationale>

        <p>If { ChannelType = StreamedMedia } is passed to
          SetSelfCapabilities, but no more specific channel class for
          audio or video has been passed to that method (in the presence
          of a ChannelDispatcher, this would mean that there is at least one
          client with that channel class in its HandlerChannelFilter, but
          no installed client has the more specific channel classes in its
          HandlerChannelFilter), then the connection manager SHOULD advertise
          support for every content type (audio or video) that it
          supports.</p>

        <tp:rationale>
          <p>This lowers the "barrier to entry" by allowing a simple client
            to say merely that it supports streamed media at all.</p>
        </tp:rationale>
      </tp:docstring>
    </property>

    <property name="InitialVideo" tp:name-for-bindings="Initial_Video"
      type="b" access="read">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for
          a video stream. This property is immutable (cannot change).</p>

        <p>In particular, note that if this property is false, this does not
          imply that an active video stream has not been added, only that no
          video stream was active at the time the channel appeared.</p>

        <p>This property is the correct way to discover whether connection
          managers, contacts etc. support video calls; it appears in
          capabilities structures in the same way as InitialAudio.</p>
      </tp:docstring><commit_msg>StreamedMedia: remove "lowering barrier to entry" wording<commit_after><?xml version="1.0" ?>
<node name="/Channel_Type_Streamed_Media_Future"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright> Copyright © 2009 Collabora Limited </tp:copyright>
  <tp:copyright> Copyright © 2009 Nokia Corporation </tp:copyright>
  <tp:license xmlns="http://www.w3.org/1999/xhtml">
    <p>This library is free software; you can redistribute it and/or
      modify it under the terms of the GNU Lesser General Public
      License as published by the Free Software Foundation; either
      version 2.1 of the License, or (at your option) any later version.</p>

    <p>This library is distributed in the hope that it will be useful,
      but WITHOUT ANY WARRANTY; without even the implied warranty of
      MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
      Lesser General Public License for more details.</p>

    <p>You should have received a copy of the GNU Lesser General Public
      License along with this library; if not, write to the Free Software
      Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
      USA.</p>
  </tp:license>
  <interface name="org.freedesktop.Telepathy.Channel.Type.StreamedMedia.FUTURE">
    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
    <tp:requires interface="org.freedesktop.Telepathy.Channel.Type.StreamedMedia"/>

    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
      <p>This interface contains functionality which we intend to incorporate
        into the <tp:dbus-ref
          namespace="org.freedesktop.Telepathy">Channel.Type.StreamedMedia</tp:dbus-ref>
        interface in future. It should be considered to be conceptually part
        of the core StreamedMedia interface, but without API or ABI
        guarantees.</p>

      <tp:rationale>
        <p>The rationale is the same as for <tp:dbus-ref
            namespace="org.freedesktop.Telepathy">Channel.FUTURE</tp:dbus-ref>.</p>
      </tp:rationale>
    </tp:docstring>

    <property name="InitialAudio" tp:name-for-bindings="Initial_Audio"
      type="b" access="read">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>If set to true in a channel request that will create a new channel,
          the connection manager should immediately attempt to establish an
          audio stream to the remote contact, making it unnecessary for the
          client to call <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">RequestStreams</tp:dbus-ref>.</p>

        <p>If this property, or InitialVideo, is passed to EnsureChannel
          (as opposed to CreateChannel), the connection manager SHOULD ignore
          these properties when checking whether it can return an existing
          channel as suitable; these properties only become significant when
          the connection manager has decided to create a new channel.</p>

        <p>If true on a requested channel, this indicates that the audio
          stream has already been requested and the client does not need to
          call RequestStreams, although it MAY still do so.</p>

        <p>If true on an unrequested (incoming) channel, this indicates that
          the remote contact initially requested an audio stream; this does
          not imply that that audio stream is still active (as indicated by
          <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">ListStreams</tp:dbus-ref>).</p>

        <p>This property is immutable (cannot change), and therefore SHOULD
          appear wherever immutable properties are reported, e.g. <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
          signals.</p>

        <tp:rationale><p>This reduces D-Bus round trips.</p></tp:rationale>

        <p>Connection managers capable of signalling audio calls to contacts
          SHOULD include a channel class in <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>
          with <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref>
          = <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref>
          and <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref>
          = Contact in the fixed properties dictionary, and InitialAudio
          (and also InitialVideo, if applicable) in the allowed properties
          list. Clients wishing to discover whether a connection manager
          can signal audio and/or video calls SHOULD use this information.</p>

        <tp:rationale>
          <p>Not all protocols support signalling video calls, and it would be
            possible (although unlikely) to have a protocol where only video,
            and not audio, could be signalled.</p>
        </tp:rationale>

        <p>Connection managers that support the <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities.DRAFT</tp:dbus-ref>
          interface SHOULD represent the capabilities of receiving audio
          and/or video calls by including a channel class in
          a contact's capabilities with ChannelType = StreamedMedia
          in the fixed properties dictionary, and InitialAudio and/or
          InitialVideo in the allowed properties list. Clients wishing to
          discover whether a particular contact is likely to be able to
          receive audio and/or video calls SHOULD use this information.</p>

        <tp:rationale>
          <p>Not all clients support video calls, and it would also be
            possible (although unlikely) to have a client which could only
            stream video, not audio.</p>
        </tp:rationale>

        <p>Clients that are willing to receive audio and/or video calls
          SHOULD include the following filters if calling <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities.DRAFT">SetSelfCapabilities</tp:dbus-ref>
          (clients of a <tp:dbus-ref
            namespace="org.freedesktop.Telepathy">ChannelDispatcher.DRAFT</tp:dbus-ref>
          SHOULD instead arrange for the ChannelDispatcher to do this,
          by including the filters in their <tp:dbus-ref
            namespace="org.freedesktop.Telepathy.Client.Handler.DRAFT">HandlerChannelFilter</tp:dbus-ref>
          properties):</p>

        <ul>
          <li>{ ChannelType = StreamedMedia }</li>
          <li>{ ChannelType = StreamedMedia, InitialAudio = true }
            if receiving calls with audio is supported</li>
          <li>{ ChannelType = StreamedMedia, InitialVideo = true }
            if receiving calls with video is supported</li>
        </ul>

        <tp:rationale>
          <p>Connection managers for protocols with capability discovery,
            like XMPP, need this information to advertise the appropriate
            capabilities for their protocol.</p>
        </tp:rationale>
      </tp:docstring>
    </property>

    <property name="InitialVideo" tp:name-for-bindings="Initial_Video"
      type="b" access="read">
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for
          a video stream. This property is immutable (cannot change).</p>

        <p>In particular, note that if this property is false, this does not
          imply that an active video stream has not been added, only that no
          video stream was active at the time the channel appeared.</p>

        <p>This property is the correct way to discover whether connection
          managers, contacts etc. support video calls; it appears in
          capabilities structures in the same way as InitialAudio.</p>
      </tp:docstring>
{'fraction_non_alphanumeric': 0.08271392043765237, 'fraction_numerical': 0.0052328001427127315, 'mean_word_length': 2.8644301470588234, 'pattern_counts': {'":': 0, '<': 221, '<?xml version=': 2, '>': 221, 'https://': 0, 'lorem ipsum': 0, 'www.': 8, 'xml': 12}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '3509926', 'n_tokens_mistral': 4495, 'n_tokens_neox': 4295, 'n_words': 1588}