← Back to branch summary

~ubuntu-branches/ubuntu/wily/telepathy-glib/wily

« back to all changes in this revision

Viewing changes to spec/Channel_Future.xml

  • Committer: Bazaar Package Importer
  • Author(s): Simon McVittie
  • Date: 2009-03-24 22:06:52 UTC
  • mfrom: (1.3.1 upstream) (17.1.10 sid)
  • Revision ID: james.westby@ubuntu.com-20090324220652-c8dvom0nsqomp23d
Tags: 0.7.28-1
* New upstream version (ABI, API added)
* Put the -dbg package in section debug, as per recent archive changes
* Remove obsolete Conflicts/Replaces with libtelepathy-glib-static-dev, which
  was never in a stable release (and probably never in Debian at all)

Show diffs side-by-side

added added

removed removed

Lines of Context:
spec/Channel_Future.xml
23
23
 
24
24
    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
25
25
      <p>This interface contains functionality which we intend to incorporate
26
 
        into the Channel interface in future. It should be considered to
 
26
        into the <tp:dbus-ref
 
27
        namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref> interface
 
28
        in future. It should be considered to
27
29
        be conceptually part of the core Channel interface, but without
28
30
        API or ABI guarantees.</p>
29
31
 
42
44
      </tp:rationale>
43
45
    </tp:docstring>
44
46
 
45
 
    <property name="TargetID" type="s" access="read">
46
 
      <tp:added version="0.17.7">(in Channel.FUTURE
47
 
        pseudo-interface)</tp:added>
48
 
      <tp:docstring>
49
 
        The string that would result from inspecting the TargetHandle
50
 
        property (i.e. the identifier in the IM protocol of the contact,
51
 
        room, etc. with which this channel communicates).
52
 
 
53
 
        <tp:rationale>
54
 
          See InitiatorID; the rationale is the same.
55
 
        </tp:rationale>
56
 
      </tp:docstring>
57
 
    </property>
58
 
 
59
 
    <property name="InitiatorHandle" type="u" tp:type="Contact_Handle"
60
 
      access="read">
61
 
      <tp:added version="0.17.7">(in Channel.FUTURE
62
 
        pseudo-interface)</tp:added>
63
 
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
64
 
        <p>The contact who initiated the channel. For channels requested by the
65
 
          local user, this MUST be the same thing as would be returned
66
 
          by Connection.GetSelfHandle() at the time the channel was
67
 
          created.</p>
68
 
 
69
 
        <tp:rationale>
70
 
          <p>The careful wording about the self-handle is because the Renaming
71
 
            interface can cause the return from Connection.GetSelfHandle to
72
 
            change. It's something of a specification bug that we don't signal
73
 
            this in the Connection interface yet.</p>
74
 
        </tp:rationale>
75
 
 
76
 
        <p>For channels requested by a remote user, this MUST be their handle.
77
 
          If unavailable or not applicable, this MUST be 0 (for instance,
78
 
          contact lists are not really initiated by anyone in particular, and
79
 
          it's easy to imagine a protocol where chatroom invitations can be
80
 
          anonymous).</p>
81
 
 
82
 
        <p>For channels with the Group interface, this SHOULD be the same
83
 
          contact who is signalled as the "Actor" causing the self-handle
84
 
          to be placed in the local-pending set.</p>
85
 
 
86
 
        <p>This SHOULD NOT be a channel-specific handle, if possible.</p>
87
 
 
88
 
        <p>It does not make sense for this property to be passed to the
89
 
          RequestChannels method on Channel.Interface.Requests.</p>
90
 
      </tp:docstring>
91
 
    </property>
92
 
 
93
 
    <property name="InitiatorID" type="s" access="read">
94
 
      <tp:added version="0.17.7">(in Channel.FUTURE
95
 
        pseudo-interface)</tp:added>
96
 
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
97
 
        <p>The string that would result from inspecting the InitiatorHandle
98
 
          property (i.e. the initiator's identifier in the IM protocol).</p>
99
 
 
100
 
        <tp:rationale>
101
 
          <p>The presence of this property avoids the following race
102
 
            condition:</p>
103
 
 
104
 
          <ul>
105
 
            <li>New StreamedMedia channel C is signalled with initiator
106
 
              handle I</li>
107
 
            <li>Client calls InspectHandles(CONTACT, [I])</li>
108
 
            <li>Channel C closes, removing the last reference to handle I</li>
109
 
            <li>InspectHandles(CONTACT, [I]) returns an error</li>
110
 
            <li>Client can indicate that a call was missed, but not who
111
 
              called!</li>
112
 
          </ul>
113
 
        </tp:rationale>
114
 
 
115
 
        <p>It does not make sense for this property to be passed to the
116
 
          RequestChannels method on Channel.Interface.Requests.</p>
 
47
    <property name="Bundle" tp:name-for-bindings="Bundle"
 
48
      type="o" access="read">
 
49
      <tp:added version="0.17.9">(in Channel.FUTURE
 
50
        pseudo-interface)</tp:added>
 
51
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
 
52
        <p>The
 
53
          <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelBundle.DRAFT</tp:dbus-ref>
 
54
          to which this channel belongs.</p>
 
55
 
 
56
        <p>A channel's Bundle property can never change.</p>
 
57
 
 
58
        <p>Older connection managers might not have this property. Clients
 
59
          (particularly the channel dispatcher) SHOULD recover by considering
 
60
          each channel to be in a bundle containing only that channel,
 
61
          distinct from all other bundles, which has no additional
 
62
          interfaces.</p>
117
63
      </tp:docstring>
118
64
    </property>
119
65