<?xml version="1.0" ?>
<node name="/Channel_Type_FileTransfer_Future"
  xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0">
  <tp:copyright>Copyright (C) 2010 Collabora Ltd.</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.FileTransfer.FUTURE"
    tp:causes-havoc="a staging area for future File Transfer Channel functionality">

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

      <tp:rationale>
        <p>If we add new functionality to the Channel interface, libraries
          that use generated code (notably telepathy-glib) will have it as
          part of their ABI forever, meaning we can't make incompatible
          changes. By using this interface as a staging area for future
          Channel functionality, we can try out new properties, signals
          and methods as application-specific extensions, then merge them
          into the core Channel interface when we have enough implementation
          experience to declare them to be stable.</p>

        <p>The name is by analogy to Python's <code>__future__</code>
          pseudo-module.</p>
      </tp:rationale>
    </tp:docstring>

    <property name="FileCollection" tp:name-for-bindings="FileCollection"
      type="s" access="read">
      <tp:added version="0.19.2">(in Channel.Type.FileTransfer.FUTURE
        pseudo-interface)</tp:added>
      <tp:docstring xmlns="http://www.w3.org/1999/xhtml">
        <p>The FileCollection to which this channel belongs.</p>

        <p>A channel's FileCollection property can never change.</p>

        <p>At least on GTalk and apparently also on iChat the user can
	  send a set of files to a contact and that contact can then
	  pick and choose which files to actually receive.

	  The CM should emit all new FT channels belonging to one collection
	  at the same time, UIs supporting this feature can then
	  bundle all these channels together in some way and show a
	  nice UI. UIs not supporting it will treat them as seperate
	  transfers, which is not great but a reasonable fallback</p>
      </tp:docstring>
    </property>

  </interface>
</node>
<!-- vim:set sw=2 sts=2 et ft=xml: -->
