Move to undrafted ContactSearch interface

3 files changed, 0 insertions, 457 deletions

diff --git a/extensions/Channel_Type_Contact_Search.xml b/extensions/Channel_Type_Contact_Search.xml
deleted file mode 100644
index 15694169f..000000000
--- a/extensions/Channel_Type_Contact_Search.xml
+++ /dev/null
@@ -1,455 +0,0 @@
-<?xml version="1.0" ?>
-<node name="/Channel_Type_Contact_Search" xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
-  <tp:copyright> Copyright © 2005-2009 Collabora Limited </tp:copyright>
-  <tp:copyright> Copyright © 2005-2009 Nokia Corporation </tp:copyright>
-  <tp:copyright> Copyright © 2006 INdT </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.ContactSearch.DRAFT2"
-    tp:causes-havoc='experimental'>
-    <tp:requires interface="org.freedesktop.Telepathy.Channel"/>
-
-    <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-      <p>A channel type for searching server-stored user directories. A new
-        channel should be requested by a client for each search attempt, and
-        closed when the search is completed or the required result has been
-        found in order to free unused handles.</p>
-
-      <p>Before searching, the
-        <tp:member-ref>AvailableSearchKeys</tp:member-ref> property should be
-        inspected to determine the valid search keys which can be provided to
-        the <tp:member-ref>Search</tp:member-ref> method. A search request is
-        then started by providing some of these terms to the Search method, and
-        the <tp:member-ref>SearchState</tp:member-ref> will change from
-        <code>Not_Started</code> to <code>In_Progress</code>.  As results are
-        returned by the server, the
-        <tp:member-ref>SearchResultReceived</tp:member-ref> signal is emitted
-        for each contact found; when the search is complete, the search state
-        will be set to <code>Completed</code>. If the search fails after Search
-        has been called, the state will change to <code>Failed</code>.  A
-        running search can be cancelled by calling
-        <tp:member-ref>Stop</tp:member-ref>.</p>
-
-      <p>If the protocol supports limiting the number of results returned by a
-        search and subsequently requesting more results, after
-        <tp:member-ref>Limit</tp:member-ref> results have been received the
-        search state will be set to <code>More_Available</code>. Clients may
-        call <tp:member-ref>More</tp:member-ref> to request another
-        <tp:member-ref>Limit</tp:member-ref> results. If allowed by the
-        connection manager, clients may specify the "page size" by specifying
-        <tp:member-ref>Limit</tp:member-ref> when calling
-        <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>.
-        </p>
-
-      <p>The client should call the channel's <tp:dbus-ref
-        namespace="org.freedesktop.Telepathy.Channel">Close</tp:dbus-ref>
-        method when it is finished with the channel, so that any handles held
-        only by the channel can be released.</p>
-
-      <p>Each channel can only be used for a single search; a new channel
-        should be requested for each subsequent search. Connection managers
-        MUST support multiple ContactSearch channels being open at once (even
-        to the same server, if applicable).</p>
-
-      <p>It does not make sense to request this channel type using <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">EnsureChannel</tp:dbus-ref>;
-        clients SHOULD request channels of this type using
-        <tp:dbus-ref
-          namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">CreateChannel</tp:dbus-ref>
-        instead.</p>
-
-      <tp:rationale>
-        <p>A contact search channel that is already in use for a different
-          search isn't useful.</p>
-      </tp:rationale>
-    </tp:docstring>
-
-    <tp:enum name="Channel_Contact_Search_State" type="u">
-      <tp:enumvalue suffix="Not_Started" value="0">
-        <tp:docstring>The search has not started</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="In_Progress" value="1">
-        <tp:docstring>The search is in progress</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="More_Available" value="2">
-        <tp:docstring>The search has paused, but more results can be retrieved
-          by calling <tp:member-ref>More</tp:member-ref>.</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Completed" value="3">
-        <tp:docstring>The search has been completed</tp:docstring>
-      </tp:enumvalue>
-      <tp:enumvalue suffix="Failed" value="4">
-        <tp:docstring>The search has failed</tp:docstring>
-      </tp:enumvalue>
-    </tp:enum>
-
-    <property name="SearchState" tp:name-for-bindings="Search_State"
-      access="read" type="u" tp:type="Channel_Contact_Search_State">
-      <tp:docstring>
-        The current state of this search channel object. Change notification
-        is via <tp:member-ref>SearchStateChanged</tp:member-ref>.
-      </tp:docstring>
-    </property>
-
-    <signal name="SearchStateChanged"
-      tp:name-for-bindings="Search_State_Changed">
-      <arg name="State" type="u" tp:type="Channel_Contact_Search_State">
-        <tp:docstring>The new search state</tp:docstring>
-      </arg>
-      <arg name="Error" type="s" tp:type="DBus_Error_Name">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          If the new state is <code>Failed</code>, the name of a D-Bus error
-          describing what went wrong. Otherwise, the empty string.
-        </tp:docstring>
-      </arg>
-      <arg name="Details" type="a{sv}" tp:type="String_Variant_Map">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>Additional information about the state transition, which may
-            include the following well-known keys:</p>
-
-          <dl>
-            <dt>debug-message (s)</dt>
-            <dd>Debugging information on the change, corresponding to the
-              message part of a D-Bus error message, which SHOULD NOT be
-              displayed to users under normal circumstances</dd>
-          </dl>
-
-          <tp:rationale>
-            <p>This argument allows for future extensions. For instance,
-              if moving to state <code>Failed</code> because the server
-              rejected one of our search terms, we could define a key
-              that indicates which terms were invalid.</p>
-          </tp:rationale>
-        </tp:docstring>
-      </arg>
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Emitted when the <tp:member-ref>SearchState</tp:member-ref> property
-          changes. The implementation MUST NOT make transitions other than the
-          following:</p>
-
-        <ul>
-          <li><code>Not_Started</code> → <code>In_Progress</code></li>
-          <li><code>In_Progress</code> → <code>More_Available</code></li>
-          <li><code>More_Available</code> → <code>In_Progress</code></li>
-          <li><code>In_Progress</code> → <code>Completed</code></li>
-          <li><code>In_Progress</code> → <code>Failed</code></li>
-        </ul>
-      </tp:docstring>
-    </signal>
-
-    <tp:simple-type name="Contact_Search_Key" type="s">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Any of the following search keys, with the indicated result for
-          the search:</p>
-
-        <dl>
-          <dt>The empty string</dt>
-          <dd>Search for the search term in some implementation-dependent
-            set of fields, using an implementation-dependent algorithm
-            (e.g. searching for each word mentioned)
-            <tp:rationale>
-              The "one big search box" approach to searching, as is familiar
-              from Google. The Sametime plugin to Pidgin appears to search in
-              this way.
-            </tp:rationale>
-          </dd>
-
-          <dt>A <tp:type>VCard_Field</tp:type></dt>
-          <dd>Search for the search term in fields matching that name (for
-            instance, <code>nickname</code> would search nicknames, and
-            <code>tel</code> would search any available phone number,
-            regardless of its work/home/mobile/... status).</dd>
-
-          <dt>A <tp:type>VCard_Field</tp:type> followed by
-            "<code>;</code>" and a
-            <tp:type>VCard_Type_Parameter</tp:type> of the form
-            "<code>type=...</code>"</dt>
-          <dd>Search for the search term in fields of that name and type
-            only (for instance, <code>tel;type=mobile</code>).</dd>
-
-          <dt><code>x-telepathy-identifier</code></dt>
-          <dd>Search for contacts whose identifier in the IM protocol
-            matches the search term (e.g. contains it as a substring)
-            <tp:rationale>
-              Otherwise, starting a search by identifier would require the UI
-              to know the vCard field name corresponding to identifiers in
-              this protocol, which might be non-standard (like
-              <code>x-jabber</code>) or not exist at all.
-            </tp:rationale>
-          </dd>
-
-          <dt><code>x-gender</code></dt>
-          <dd>For the search term "male" or "female", search only for contacts
-            listed as male or female, respectively. The results for other
-            search terms are undefined; it is likely that contacts with
-            unspecified gender will only be matched if this search key
-            is omitted from the request.
-            <tp:rationale>
-              Examples in XEP-0055 suggest this usage, and at least Gadu-Gadu
-              also supports limiting search results by gender.
-            </tp:rationale>
-          </dd>
-
-          <dt><code>x-n-family</code></dt>
-          <dd>Search for the search term in contacts' family names
-            (the first component of the vCard field <code>n</code>).
-            <tp:rationale>
-              Gadu-Gadu and TOC seem to support this mode of searching.
-            </tp:rationale>
-          </dd>
-
-          <dt><code>x-n-given</code></dt>
-          <dd>Search for the search term in contacts' given names
-            (the second component of the vCard field <code>n</code>).
-            <tp:rationale>
-              As for <code>x-n-family</code>.
-            </tp:rationale>
-          </dd>
-
-          <dt><code>x-online</code></dt>
-          <dd>For the search term "yes", search only for contacts who are
-            currently online. The results for other search terms are undefined.
-            <tp:rationale>Gadu-Gadu appears to support this.</tp:rationale>
-          </dd>
-
-          <dt><code>x-adr-locality</code></dt>
-          <dd>Search for the search term as a locality or city (the fourth
-            component of the vCard field <code>adr</code>).
-            <tp:rationale>
-              Gadu-Gadu and TOC appear to support this.
-            </tp:rationale>
-          </dd>
-        </dl>
-      </tp:docstring>
-    </tp:simple-type>
-
-    <property name="Limit" type="u" access="read"
-      tp:name-for-bindings="Limit">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>If supported by the protocol, the maximum number of results that
-          should be returned, where <code>0</code> represents no limit. If the
-          protocol does not support limiting results, this should be
-          <code>0</code>.</p>
-
-        <p>For example, if the terms passed to
-          <tp:member-ref>Search</tp:member-ref> match <i>Antonius</i>,
-          <i>Bridget</i> and <i>Charles</i> and this property is
-          <code>2</code>, the search service SHOULD only return <i>Antonius</i>
-          and <i>Bridget</i>.</p>
-
-        <p>This property cannot change during the lifetime of the channel.
-          This property SHOULD be in the Allowed_Properties of a
-          <tp:type>Requestable_Channel_Class</tp:type> if and only if the
-          protocol supports specifying a limit; implementations SHOULD use
-          <code>0</code> as the default if possible, or a protocol-specific
-          sensible default otherwise.</p>
-      </tp:docstring>
-    </property>
-
-    <property name="AvailableSearchKeys" type="as" access="read"
-      tp:name-for-bindings="Available_Search_Keys">
-      <tp:docstring>
-        The set of search keys supported by this channel. Example values
-        include [""] (for protocols where several address fields are
-        implicitly searched) or ["x-n-given", "x-n-family", "nickname",
-        "email"] (for XMPP XEP-0055, without extensibility via Data Forms).
-        This property cannot change during the lifetime of a channel.
-
-        <tp:rationale>
-          It can be in the <tp:dbus-ref
-            namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>
-          signal for round-trip reduction.
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-    <tp:mapping name="Contact_Search_Map">
-      <tp:docstring>A map from search keys to search terms.</tp:docstring>
-      <tp:member name="Key" type="s" tp:type="Contact_Search_Key">
-        <tp:docstring>
-          The search key to match against
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member name="Term" type="s">
-        <tp:docstring>
-          The term or terms to be searched for in the search key; depending on
-          the protocol and the server implementation, this may be matched by
-          exact or approximate equality, substring matching, word matching
-          or any other matching algorithm
-        </tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <method name="Search" tp:name-for-bindings="Search">
-      <arg direction="in" name="Terms"
-        type="a{ss}" tp:type="Contact_Search_Map">
-        <tp:docstring>
-          A dictionary mapping search key names to the desired values
-        </tp:docstring>
-      </arg>
-      <tp:docstring>
-        Send a request to start a search for contacts on this connection. This
-        may only be called while the <tp:member-ref>SearchState</tp:member-ref>
-        is Not_Started; a valid search request will cause the
-        <tp:member-ref>SearchStateChanged</tp:member-ref> signal to be emitted
-        with the state In_Progress.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The <tp:member-ref>SearchState</tp:member-ref> is no longer
-            Not_Started, so this method is no longer available.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.InvalidArgument">
-          <tp:docstring>
-            The search terms included something this connection manager cannot
-            search for.
-          </tp:docstring>
-        </tp:error>
-        <tp:error name="org.freedesktop.Telepathy.Error.NetworkError"/>
-      </tp:possible-errors>
-    </method>
-
-    <method name="More" tp:name-for-bindings="More">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        Request that a search in <tp:member-ref>SearchState</tp:member-ref>
-        <code>More_Available</code> move back to state <code>In_Progress</code>
-        and continue listing up to <tp:member-ref>Limit</tp:member-ref> more results.
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The <tp:member-ref>SearchState</tp:member-ref> is not
-            <code>More_Available</code>.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <method name="Stop" tp:name-for-bindings="Stop">
-      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-        <p>Stop the current search. This may not be called while the
-          <tp:member-ref>SearchState</tp:member-ref> is Not_Started. If called
-          while the SearchState is In_Progress,
-          <tp:member-ref>SearchStateChanged</tp:member-ref> will be emitted,
-          with the state Failed and the error
-          <code>org.freedesktop.Telepathy.Errors.Cancelled</code>.</p>
-
-        <p>Calling this method on a search in state Completed or Failed
-          succeeds, but has no effect.</p>
-
-        <tp:rationale>
-          <p>Specifying Stop to succeed when the search has finished means that
-            clients who call Stop just before receiving
-            <tp:member-ref>SearchStateChanged</tp:member-ref> don't have to
-            handle a useless error.</p>
-        </tp:rationale>
-
-        <p>Depending on the protocol, the connection manager may not be
-          able to prevent the server from sending further results after this
-          method returns; if this is the case, it MUST ignore any further
-          results.</p>
-      </tp:docstring>
-      <tp:possible-errors>
-        <tp:error name="org.freedesktop.Telepathy.Error.NotAvailable">
-          <tp:docstring>
-            The <tp:member-ref>SearchState</tp:member-ref> is Not_Started, so
-            this method is not yet available.
-          </tp:docstring>
-        </tp:error>
-      </tp:possible-errors>
-    </method>
-
-    <tp:mapping name="Contact_Search_Result_Map">
-      <tp:docstring>A map from contact handle to search result.</tp:docstring>
-      <tp:member name="Contact" type="u" tp:type="Contact_Handle">
-        <tp:docstring>
-          An integer handle for the contact.
-        </tp:docstring>
-      </tp:member>
-
-      <tp:member name="Info" type="a(sasas)" tp:type="Contact_Info_Field[]">
-        <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
-          <p>An array of fields representing information about this
-            contact, in the same format used in the <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface">ContactInfo.DRAFT</tp:dbus-ref>
-            interface. It is possible that a separate call to <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection.Interface.ContactInfo.DRAFT">RequestContactInfo</tp:dbus-ref>
-            would return more information than this signal provides.</p>
-
-          <p>This array SHOULD include the <code>x-telepathy-identifier</code>
-            field, whose values matches the result of calling <tp:dbus-ref
-              namespace="org.freedesktop.Telepathy.Connection">InspectHandles</tp:dbus-ref>
-            on the Contact handle.</p>
-
-          <tp:rationale>
-            <p>UIs will most likely want to show the identifier to the user;
-              while they could do this by inspecting the signalled handle,
-              including it in this signal is cheap and removes a roundtrip to
-              look it up.</p>
-          </tp:rationale>
-        </tp:docstring>
-      </tp:member>
-    </tp:mapping>
-
-    <signal name="SearchResultReceived"
-      tp:name-for-bindings="Search_Result_Received">
-      <arg name="Result" type="a{ua(sasas)}" tp:type="Contact_Search_Result_Map">
-        <tp:docstring>A mapping from contact handle to an array of fields
-          representing information about this contact. Handles in this mapping
-          MUST remain valid until the Channel closes.</tp:docstring>
-      </arg>
-      <tp:docstring>
-        Emitted when a some search results are received from the server.
-        This signal can be fired arbitrarily many times so clients MUST NOT
-        assume they'll get only one signal.
-      </tp:docstring>
-    </signal>
-
-    <property name="Server" tp:name-for-bindings="Server"
-      type="s" access="read">
-      <tp:docstring>
-        <p>For protocols which support searching for contacts on multiple
-          servers with different DNS names (like XMPP), the DNS name of the
-          server being searched by this channel, e.g.
-          "characters.shakespeare.lit".  Otherwise, the empty string.</p>
-
-        <tp:rationale>
-          <p>XEP 0055 defines a mechanism for XMPP clients to search services
-            of their choice for contacts, such as users.jabber.org (the "Jabber
-            User Directory").</p>
-        </tp:rationale>
-
-        <p>This property cannot change during the lifetime of the channel.
-          This property SHOULD be in the Allowed_Properties of a
-          <tp:type>Requestable_Channel_Class</tp:type> if and only if the
-          protocol supports querying multiple different servers;
-          implementations SHOULD use a sensible default if possible if this
-          property is not specified in a channel request.</p>
-
-        <tp:rationale>
-          <p>This allows a client to perform searches on a protocol it knows
-            nothing about without requiring the user to guess a valid server's
-            hostname.</p>
-        </tp:rationale>
-      </tp:docstring>
-    </property>
-
-  </interface>
-</node>
-<!-- vim:set sw=2 sts=2 et ft=xml: -->
diff --git a/extensions/Makefile.am b/extensions/Makefile.am
index 6cc215001..bf725734b 100644
--- a/extensions/Makefile.am
+++ b/extensions/Makefile.am
@@ -18,7 +18,6 @@ EXTRA_DIST = \
     Connection_Future.xml \
     Connection_Interface_Gabble_Decloak.xml \
     Connection_Interface_Mail_Notification.xml \
-    Channel_Type_Contact_Search.xml \
     Gabble_Plugin_Gateways.xml \
     Gabble_Plugin_Test.xml \
     OLPC_Activity_Properties.xml \
diff --git a/extensions/all.xml b/extensions/all.xml
index 7ea6c0cfc..cd099b7e9 100644
--- a/extensions/all.xml
+++ b/extensions/all.xml
@@ -42,7 +42,6 @@ Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA</p>
 <xi:include href="OLPC_Channel_Type_BuddyView.xml"/>
 <xi:include href="OLPC_Channel_Type_ActivityView.xml"/>
 
-<xi:include href="Channel_Type_Contact_Search.xml"/>
 <xi:include href="Channel_Type_FileTransfer_Future.xml"/>
 <xi:include href="Connection_Interface_Gabble_Decloak.xml"/>
 <xi:include href="Channel_Interface_Conference.xml"/>