tp_cli_channel_dispatcher_interface_messages1_call_send_message ()

TpProxyPendingCall *
tp_cli_channel_dispatcher_interface_messages1_call_send_message
                               (TpChannelDispatcher *proxy,
                                gint timeout_ms,
                                const gchar *in_Account,
                                const gchar *in_Target_ID,
                                const GPtrArray *in_Message,
                                guint in_Flags,
                                tp_cli_channel_dispatcher_interface_messages1_callback_for_send_message callback,
                                gpointer user_data,
                                GDestroyNotify destroy,
                                GObject *weak_object);

Start a SendMessage method call.

<tp:docstring xmlns="http://www.w3.org/1999/xhtml"> <p>Submit a message to the server for sending, like the <tp:dbus-ref namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref> method.</p> <p>If the <var>Account</var> is connected and a Text channel to the <var>Target_ID</var> already exists, this method is equivalent to sending the same message via that channel.</p> <p>Otherwise, this method creates a channel (connecting the Account if appropriate), sends the desired message, and closes the channel as if via <tp:dbus-ref namespace="imt1">Channel.Close</tp:dbus-ref>, without acknowledging any messages received on that channel during that time.</p> <p>If any messages are received on that channel before it is closed, a correct connection manager implementation will reopen the channel when it is closed, resulting in those &quot;rescued&quot; messages being processed by the system's normal <tp:dbus-ref namespace="imt1.Client">Handler</tp:dbus-ref> for text channels. In particular, this deals with the situation where a successful or failed delivery report is received before the channel is closed.</p> <tp:rationale> <p>Expecting a trivial client (perhaps a send-only IRC bot, or a simple SMS-sending API) to go through all those steps to send a message seems somewhat unreasonable. Having this as a method in the ChannelDispatcher lets it take some short-cuts if required, and centralizes the implementation to reduce the risk of mistakes that cause message loss.</p> </tp:rationale> <p>The ChannelDispatcher SHOULD support this method for any connection manager that would accept channel requests of this form:</p> <pre> { …<tp:dbus-ref namespace="imt1">Channel.ChannelType</tp:dbus-ref>: …<tp:dbus-ref namespace="imt1">Channel.Type.Text</tp:dbus-ref>, …<tp:dbus-ref namespace="imt1">Channel.TargetEntityType</tp:dbus-ref>: <tp:value-ref type="Entity_Type">Contact</tp:value-ref>, …<tp:dbus-ref namespace="imt1">Channel.TargetID</tp:dbus-ref>: <var>Target_ID</var> }</pre> <p>However, if the connection manager provides additional APIs (such as a way to open &quot;send-only&quot; channels), the ChannelDispatcher MAY use those: it is not required to use those exact request parameters.</p> <p>This method may raise any error that would be raised by the <tp:dbus-ref namespace="imt1.Connection.Interface">Requests.EnsureChannel</tp:dbus-ref> or <tp:dbus-ref namespace="imt1.Channel.Type">Text.SendMessage</tp:dbus-ref> methods, or signalled by the <tp:dbus-ref namespace="imt1.ChannelRequest">Failed</tp:dbus-ref> signal.</p>

tp_cli_channel_dispatcher_interface_messages1_callback_for_send_message ()

void
(*tp_cli_channel_dispatcher_interface_messages1_callback_for_send_message)
                               (TpChannelDispatcher *proxy,
                                const gchar *out_Token,
                                const GError *error,
                                gpointer user_data,
                                GObject *weak_object);

Signature of the callback called when a SendMessage method call succeeds or fails.

struct TpChannelDispatcher

struct TpChannelDispatcher;

The Channel Dispatcher's main D-Bus API is used to request channels, which is done by calling tp_cli_channel_dispatcher_call_create_channel() or tp_cli_channel_dispatcher_call_ensure_channel() as appropriate.

The Telepathy Channel Dispatcher is also responsible for responding to new channels and launching client processes to handle them. However, clients that can work with incoming channels do not have to call methods on the channel dispatcher: instead, they must register with the channel dispatcher passively, by taking a bus name starting with TP_CLIENT_BUS_NAME_BASE and implementing the TpSvcClient interface. See the Telepathy D-Bus Interface Specification for details.

This proxy is usable but incomplete: convenience methods will be added in a later version of telepathy-glib.

Since 0.7.32

struct TpChannelDispatcherClass

struct TpChannelDispatcherClass {
};

The class of a TpChannelDispatcher.