spec: conference interface has been undrafted

The properties are implemented in tp-python

4 files changed, 3 insertions, 192 deletions

diff --git a/butterfly/Channel_Interface_Conference.py b/butterfly/Channel_Interface_Conference.py
deleted file mode 100644
index 7a02ed2..0000000
--- a/butterfly/Channel_Interface_Conference.py
+++ /dev/null
@@ -1,155 +0,0 @@
-# -*- coding: utf-8 -*-
-# Generated from the Telepathy spec
-"""Copyright © 2009 Collabora Limited
-Copyright © 2009 Nokia Corporation
-
-    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.
-
-    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.
-
-    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.
-  
-"""
-
-import dbus.service
-
-CHANNEL_INTERFACE_CONFERENCE = 'org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT'
-
-class ChannelInterfaceConference(dbus.service.Interface):
-    """\
-      An interface for multi-user conference channels that can "continue
-        from" one or more individual channels.
-
-      
-        This interface addresses freedesktop.org bug
-            #24906 (GSM-compatible conference calls) and bug
-            #24939 (upgrading calls and chats to multi-user).
-          See those bugs for rationale and use cases.
-
-        Examples of usage:
-
-        Active and held GSM calls C1, C2 can be merged into a single
-          channel Cn with the Conference interface, by calling
-          CreateChannel({...ChannelType: ...Call,
-            ...InitialChannels: [C1, C2]})
-          which returns Cn.
-
-        An XMPP 1-1 conversation C1 can be continued in a newly created
-          multi-user chatroom Cn by calling
-          CreateChannel({...ChannelType: ...Text,
-            ...InitialChannels: [C1]})
-          which returns Cn.
-
-        An XMPP 1-1 conversation C1 can be continued in a specified
-          multi-user chatroom by calling
-          CreateChannel({...ChannelType: ...Text, ...HandleType: ROOM,
-            ...TargetID: 'telepathy@conf.example.com',
-            ...InitialChannels: [C1]})
-          which returns a Conference channel.
-
-        Either of the XMPP cases could work for Call channels, to
-          upgrade from 1-1 Jingle to multi-user Jingle. Any of the XMPP cases
-          could in principle work for link-local XMPP (XEP-0174).
-
-        The underlying switchboard representing an MSN 1-1 conversation C1
-          with a contact X can be moved to a representation as a nameless
-          chatroom, Cn, to which more contacts can be invited, by calling
-          CreateChannel({...ChannelType: ...Text,
-            ...InitialChannels: [C1]})
-          which returns Cn. C1 SHOULD remain open, with no underlying
-          switchboard attached. If X establishes a new switchboard with the
-          local user, C1 SHOULD pick up that switchboard rather than letting
-          it create a new channel.
-          [FIXME: should it?]
-          Similarly, if the local user sends a message in C1, then
-          a new switchboard to X should be created and associated with C1.
-
-        XMPP and MSN do not natively have a concept of merging two or more
-          channels C1, C2... into one channel, Cn. However, the GSM-style
-          merging API can be supported on XMPP and MSN, as an API short-cut
-          for upgrading C1 into a conference Cn (which invites the
-          TargetHandle of C1 into Cn), then immediately inviting the
-          TargetHandle of C2, the TargetHandle of C3, etc. into Cn as well.
-
-        With a suitable change of terminology, Skype has behaviour similar
-          to MSN.
-      
-
-      The Group MAY have channel-specific handles for participants;
-        clients SHOULD support both Conferences that have channel-specific handles,
-        and those that do not.
-
-      
-        In the GSM case, the Conference's Group interface MAY have
-          channel-specific handles, to reflect the fact that the identities of
-          the participants might not be known - it can be possible to know that
-          there is another participant in the Conference, but not know who
-          they are.
-          [FIXME: fact check from GSM gurus needed]
-        
-
-        In the XMPP case, the Conference's Group interface SHOULD have
-          channel-specific handles, to reflect the fact that the participants
-          have MUC-specific identities, and the user might also be able to see
-          their global identities, or not.
-
-        In most other cases, including MSN and link-local XMPP, the
-          Conference's Group interface SHOULD NOT have channel-specific
-          handles, since users' identities are always visible.
-      
-
-      Connection managers implementing channels with this interface
-        MUST NOT allow the object paths of channels that could be merged
-        into a Conference to be re-used, unless the channel re-using the
-        object path is equivalent to the channel that previously used it.
-
-      
-        If you upgrade some channels into a conference, and then close
-          the original channels, InitialChannels
-          (which is immutable) will contain paths to channels which no longer
-          exist. This implies that you should not re-use channel object paths,
-          unless future incarnations of the path are equivalent.
-
-        For instance, on protocols where you can only have
-          zero or one 1-1 text channels with Emily at one time, it would
-          be OK to re-use the same object path for every 1-1 text channel
-          with Emily; but on protocols where this is not true, it would
-          be misleading.
-      
-
-    """
-
-    def __init__(self):
-        self._interfaces.add('org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT')
-
-    @dbus.service.signal('org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT', signature='o')
-    def ChannelMerged(self, Channel):
-        """
-        Emitted when a new channel is added to the value of
-          Channels.
-      
-        """
-        pass
-  
-    @dbus.service.signal('org.freedesktop.Telepathy.Channel.Interface.Conference.DRAFT', signature='o')
-    def ChannelRemoved(self, Channel):
-        """
-        Emitted when a channel is removed from the value of
-          Channels, either because it closed
-          or because it was split using the Splittable.DRAFT.Split method.
-
-        [FIXME: relative ordering of this vs. Closed? Do we
-            care?]
-      
-        """
-        pass
-  
diff --git a/butterfly/Makefile.am b/butterfly/Makefile.am
index b2bbbb3..4317de1 100644
--- a/butterfly/Makefile.am
+++ b/butterfly/Makefile.am
@@ -4,7 +4,6 @@ butterflydir = $(pythondir)/butterfly
 butterfly_PYTHON = \
 	aliasing.py \
 	capabilities.py \
-	Channel_Interface_Conference.py \
 	Connection_Interface_Mail_Notification.py \
 	connection.py \
 	debug.py \
diff --git a/butterfly/channel/conference.py b/butterfly/channel/conference.py
index c7e0454..a078dfe 100644
--- a/butterfly/channel/conference.py
+++ b/butterfly/channel/conference.py
@@ -26,7 +26,6 @@ import papyon
 import papyon.event
 
 from butterfly.channel.muc import ButterflyMucChannel
-from butterfly.Channel_Interface_Conference import *
 
 __all__ = ['ButterflyConferenceChannel']
 
@@ -34,11 +33,11 @@ logger = logging.getLogger('Butterfly.ConferenceChannel')
 
 class ButterflyConferenceChannel(
         ButterflyMucChannel,
-        ChannelInterfaceConference):
+        telepathy.server.ChannelInterfaceConference):
 
     def __init__(self, conn, manager, conversation, props, object_path=None):
         ButterflyMucChannel.__init__(self, conn, manager, conversation, props, object_path)
-        ChannelInterfaceConference.__init__(self)
+        telepathy.server.ChannelInterfaceConference.__init__(self)
 
         _, _, handle = manager._get_type_requested_handle(props)
 
@@ -61,36 +60,6 @@ class ButterflyConferenceChannel(
         # Invite contacts in InitialInvitee{IDs,Handles}
         self._invite_initial_invitees(props, ic)
 
-        # D-Bus properties for conference interface
-        self._implement_property_get(CHANNEL_INTERFACE_CONFERENCE, {
-            'Channels':
-                lambda: dbus.Array(self._conference_channels, signature='o'),
-            'InitialChannels':
-                lambda: dbus.Array(self._conference_initial_channels,
-                                   signature='o'),
-            'InitialInviteeHandles':
-                lambda: dbus.Array(
-                    [h.get_id() for h in self._conference_initial_invitees],
-                    signature='u'),
-            'InitialInviteeIDs':
-                lambda: dbus.Array(
-                    [h.get_name() for h in self._conference_initial_invitees],
-                    signature='s'),
-            'InvitationMessage':
-                lambda: dbus.String(''),
-            'SupportsNonMerges':
-                lambda: dbus.Boolean(True)
-            })
-
-        # Immutable conference properties
-        self._add_immutables({
-                'InitialChannels': CHANNEL_INTERFACE_CONFERENCE,
-                'InitialInviteeIDs': CHANNEL_INTERFACE_CONFERENCE,
-                'InitialInviteeHandles': CHANNEL_INTERFACE_CONFERENCE,
-                'InvitationMessage': CHANNEL_INTERFACE_CONFERENCE,
-                'SupportsNonMerges': CHANNEL_INTERFACE_CONFERENCE
-                })
-
     def _get_initial_channels(self, props):
         logger.info('Getting channels from InitialChannels')
         ic_paths = props[CHANNEL_INTERFACE_CONFERENCE + '.InitialChannels']
diff --git a/butterfly/channel_manager.py b/butterfly/channel_manager.py
index 44f4f85..c2715be 100644
--- a/butterfly/channel_manager.py
+++ b/butterfly/channel_manager.py
@@ -33,8 +33,6 @@ from butterfly.channel.file_transfer import ButterflyFileTransferChannel
 from butterfly.channel.media import ButterflyMediaChannel
 from butterfly.handle import ButterflyHandleFactory
 
-from butterfly.Channel_Interface_Conference import CHANNEL_INTERFACE_CONFERENCE
-
 __all__ = ['ButterflyChannelManager']
 
 logger = logging.getLogger('Butterfly.ChannelManager')
@@ -168,7 +166,7 @@ class ButterflyChannelManager(telepathy.server.ChannelManager):
 
         # MUC which has been upgraded from a 1-1 chat
         elif handle.get_type() == telepathy.HANDLE_TYPE_NONE \
-                and CHANNEL_INTERFACE_CONFERENCE + '.InitialChannels' in props:
+                and telepathy.CHANNEL_INTERFACE_CONFERENCE + '.InitialChannels' in props:
             channel = ButterflyConferenceChannel(self._conn, self, conversation, props,
                 object_path=path)