[Bug 49505] somewhat high-level API to add client channel filters

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=49505

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #4)
> Is that still something we want for 1.0 ? We already replaced TpAsv by
> GVariant in 'next'.

Well, there are two parts to what I originally wrote:

> Continuing our campaign against GHashTables masquerading as high-level API,
> here is something that's not so good:
> 
> -   * |[
> -   * tp_base_client_take_handler_filter (handler, tp_asv_new (
> -   *               TP_PROP_CHANNEL_CHANNEL_TYPE, G_TYPE_STRING,
> TP_IFACE_CHANNEL_TYPE_FILE_TRANSFER,
> -   *               TP_PROP_CHANNEL_TARGET_HANDLE_TYPE, G_TYPE_UINT,
> TP_HANDLE_TYPE_CONTACT,
> -   *               TP_PROP_CHANNEL_REQUESTED, G_TYPE_BOOLEAN, FALSE,
> -   *              
> TP_PROP_CHANNEL_INTERFACE_FILE_TRANSFER_METADATA_SERVICE_NAME,
> G_TYPE_STRING, "service.name",
> -   *               NULL));
> 
> and my proposal to replace it:
> 
> + * filter = tp_channel_filter_new_for_file_transfer ("service.name");
> + * tp_channel_filter_require_locally_requested (filter, FALSE);
> + * tp_base_client_take_handler_filter_object (client, filter);

One is to use GVariant instead of GHashTable for the low-level API that
requires you to speak fluent D-Bus. Yes, done.

The other is to be able to say "I handle file transfers whose service name is
service.name" without using telepathy-glib-dbus.h and coupling your source code
to the specifics of the D-Bus API. We don't have that.

In practice, this means nobody can write a Telepathy Handler (or Observer or
Approver) without having our D-Bus API in their source code (and keeping up
with, e.g., moving from FileTransfer1 to FileTransfer2 if we redo how hashing
works post-1.0).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.