Tp::Service::ChannelInterfaceDestroyableAdaptor Class Reference

| Home · All Classes · All Namespaces · Modules · Functions · Files

Public Slots | List of all members
Tp::Service::ChannelInterfaceDestroyableAdaptor Class Reference
Channel service implementation

`#include <TelepathyQt/_gen/svc-channel.h>`

Inherits Tp::AbstractAdaptor.

## Public Slots
void | Destroy (const QDBusMessage &dbusMessage)

## Additional Inherited Members
Public Member Functions inherited from Tp::AbstractAdaptor
| AbstractAdaptor (const QDBusConnection &connection, QObject *adaptee, QObject *parent)
| ~AbstractAdaptor ()
QDBusConnection | dbusConnection () const
QObject * | adaptee () const

## Detailed Description

Adaptor class providing a 1:1 mapping of the D-Bus interface "org.freedesktop.Telepathy.Channel.Interface.Destroyable".

## Member Function Documentation

void Tp::Service::ChannelInterfaceDestroyableAdaptor::Destroy | ( | const QDBusMessage & | dbusMessage | ) |
| slot

Begins a call to the exported D-Bus method `Destroy` on this object.

Adaptees should export this method as a Qt slot with the following signature: void destroy(const Tp::Service::ChannelInterfaceDestroyableAdaptor::DestroyContextPtr &context);

Implementations should call MethodInvocationContext::setFinished (or setFinishedWithError accordingly) on the received context object once the method has finished processing.

Close the channel abruptly, possibly with loss of data. The connection manager MUST NOT re-create the channel unless/until more events occur.

The main motivating situation for this method is that when a Text channel with pending messages is closed with Close, it comes back as an incoming channel (to avoid a race between Close and an incoming message). If Destroy is called on a Text channel, the CM should delete all pending messages and close the channel, and the channel shouldn't be re-created until/unless another message arrives.

Most clients SHOULD call ChannelInterface::Close() instead. However, if a client explicitly intends to destroy the channel with possible loss of data, it SHOULD call this method if this interface is supported (according to the ChannelInterface::Interfaces property), falling back to Close if not.

In particular, channel dispatchers SHOULD use this method if available when terminating channels that cannot be handled correctly (for instance, if no handler has been installed for a channel type, or if the handler crashes repeatedly).

Connection managers do not need to implement this interface on channels where Close and Destroy would be equivalent.

Callers need to be able to fall back to Close in any case.