| Summary: |
RequestableChannelClass should have high-level API |
| Product: |
Telepathy
|
Reporter: |
Olli Salli <ollisal> |
| Component: |
tp-qt | Assignee: |
Telepathy bugs list <telepathy-bugs> |
| Status: |
RESOLVED
FIXED
|
QA Contact: |
Telepathy bugs list <telepathy-bugs> |
| Severity: |
enhancement
|
|
|
| Priority: |
medium
|
|
|
| Version: |
git master | |
|
| Hardware: |
All | |
|
| OS: |
All | |
|
| Whiteboard: |
|
|
i915 platform:
|
|
i915 features:
|
|
|---|
| Bug Depends on: |
|
|
|
| Bug Blocks: |
29486
|
|
|
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.
The D-Bus spec generated RequestableChannelClass struct is spreading across TpQt4 APIs at an alarming rate (:D). While we already have some higher-level accessors such as ContactCapabilities::supportsMediaCalls(), should we, in fact, have a higher-level ChannelClass object (similarly to Channel::GroupMemberChangeDetails) wrapping the variant map and having accessors to the well-known channel immutable keys (such as {set,has,}ChannelType), etc. There should also be something to manipulate the optional parameters array with. I believe this would be most useful for the planned filtering API additions (bug #29090), specifically constructing filter channel classes and making sense of existing filters. It would also provide a middle ground between the CapabilitiesBase::supports() accessors and the bare variant map access still needed for some tasks (at least in extensions).