From 8a381d874b5133f660723b717b2c23bdf1be1577 Mon Sep 17 00:00:00 2001 From: Louis-Francis Ratté-Boulianne Date: Tue, 9 Nov 2010 16:02:48 -0500 Subject: spec: conference interface has been undrafted The properties are implemented in tp-python --- butterfly/Channel_Interface_Conference.py | 155 ------------------------------ butterfly/Makefile.am | 1 - butterfly/channel/conference.py | 35 +------ butterfly/channel_manager.py | 4 +- 4 files changed, 3 insertions(+), 192 deletions(-) delete mode 100644 butterfly/Channel_Interface_Conference.py 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) -- cgit v1.2.3