Bug 26979 - Can't support multiple requestable channel classes for the same channel type
Summary: Can't support multiple requestable channel classes for the same channel type
Status: RESOLVED FIXED
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-python (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL: http://git.collabora.co.uk/?p=user/jo...
Whiteboard:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2010-03-09 06:56 UTC by Jonny Lamb
Modified: 2010-03-12 15:03 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments

Description Jonny Lamb 2010-03-09 06:56:50 UTC 
The drunken haze I was under when I implemented the Requests interface and the channel manager assisted in adding an annoying oversight into the RequestableChannelClasses retrieving. For example:

fixed = {telepathy.CHANNEL_INTERFACE + '.ChannelType': telepathy.CHANNEL_TYPE_TEXT,
    telepathy.CHANNEL_INTERFACE + '.TargetHandleType': dbus.UInt32(telepathy.HANDLE_TYPE_CONTACT)}

self._implement_channel_class(telepathy.CHANNEL_TYPE_TEXT,
     self._get_text_channel, fixed, [CHANNEL_INTERFACE_CONFERENCE + '.InitialChannels'])

This is great if the only RCC you want for text channels is:

({ChannelType: TEXT, TargetHandleType: CONTACT}, [InitialChannels])

But that's not always the case.

Sigh.
Comment 1 Jonny Lamb 2010-03-10 11:43:36 UTC 
I've fixed this in my misc-for-conference branch. I've already asked Olivier to review it.

For reference, my conference butterfly branch uses this new function.
Comment 2 Jonny Lamb 2010-03-12 15:03:16 UTC 
Fixed in 0.15.17.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.