[Telepathy] tp_cli_connection_manager_run_request_connection(): What parameter types.

[Will Thompson]

On 27/10/08 16:07, Murray Cumming wrote:
> On Sat, 2008-10-25 at 11:14 +0100, Will Thompson wrote:
>   
>>>   GHashTable *parameters = g_hash_table_new (NULL, NULL);
>>>   g_hash_table_insert (parameters, "s:account", "murrayc at murrayc.com");
>>>   g_hash_table_insert (parameters, "s:server", "murrayc.com");
>>>   g_hash_table_insert (parameters, "s:password", "TODO");
>>>   
>>>       
>> should become something like (untested):
>>
>>     GValue *value;
>>     GHashTable *parameters = g_hash_table_new_full (NULL, NULL, NULL, tp_g_value_slice_free);
>>
>>     value = tp_g_value_slice_new (G_TYPE_STRING);
>>     g_value_set_static_string (value, "murrayc at murrayc.com");
>>     g_hash_table_insert (parameters, "account", value);
>>
>>     /* on XMPP, you shouldn't need to set the server parameter, since presumably you have an appropriate SRV record on murrayc.com. */
>>
>>     value = tp_g_value_slice_new (G_TYPE_STRING);
>>     g_value_set_static_string (value, "myhovercraftisfullofeels");
>>     g_hash_table_insert (parameters, "password", value);
>>     
>
>
> Thanks. Shouldn't there be a varargs version of this function. It's
> generally unpleasant to deal with GValues. For instance,
> http://library.gnome.org/devel/gtk/unstable/GtkListStore.html#gtk-list-store-set
>   

Well, we could construct a function that lets you say something like:

    g_hash_table_build (parameters, "account", G_TYPE_STRING,
    "murrayc at murrayc.com", "require-encryption", G_TYPE_BOOLEAN, TRUE,
    NULL);

but I don't really see what that would buy over:

    // note: these functions do not exist yet because i haven't had time
    to write them
    tp_asv_set_string (parameters, "account", "murrayc at ...");
    tp_asv_set_bool (parameters, "require-encryption", TRUE);

(which will also avoid dealing with GValues when it exists).

> So now my connection request has succeeded, giving me a "A D-Bus service
> name where the new Connection object can be found" and "The D-Bus object
> path to the Connection on this service". I guess I can use these with
> tp_connection_new(),
> http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-connection.html#tp-connection-new
> but why didn't I just get a TpConnection object directly? And shouldn't
> the API reference documentation tell me these things?
>   

Because TpConnectionManager is kind of rough around the edges — rougher
than we thought, as you have discovered :-) — and the function you
called's documentation is derived directly from the D-Bus specification,
which is language- and binding-independent. We should probably add a
tp_connection_manager_request_connection () helper which passes a
TpConnection to the callback. This is
http://bugs.freedesktop.org/show_bug.cgi?id=18248 .

> Also, when running this twice (without using tp_connection_new), I
> noticed that the connection seems to be system-wide, because I got this
> error the second time from 
> tp_cli_connection_manager_run_request_connection()
> "Connection manager already has a connection to this account."
>
> So 
> a) How can I just "get" the existing connection if it exists.
>   

You can't. Ultimately you'd use the AccountManager API, but
MissionControl doesn't implement it at the moment.

> and
> b) How should I "release" the connection?
>   

By calling Disconnect() on the object you were given back by
request_connection() the first time around. We were discussing this
issue of lost-in-space connections recently; see
http://bugs.freedesktop.org/show_bug.cgi?id=18058 .

>   
>> Telepathy-GLib has helper methods to get values of various types out of
>> such string → GValue maps (namely tp_asv_get_…, where “a{sv}” is the
>> D-Bus type signature of these dictionaries), but none to set values. We
>> should add some (created
>> http://bugs.freedesktop.org/show_bug.cgi?id=18220 ); then this would
>> become:
>>
>>     GHashTable *parameters = g_hash_table_new (NULL, NULL, NULL, tp_g_value_slice_free);
>>
>>     tp_asv_set_static_string (parameters, "account", "murrayc at murrayc.com");
>>     tp_asv_set_static_string (parameters, "password", "myzeppelinisfullofbees");
>>
>>       
>>
>> which is somewhat more palatable, and is (sadly) about the best we could
>> hope for in a C binding for such a D-Bus API. We could conceivably add
>> tp_connection_parameters_set_password (GHashTable *parameters, const
>> gchar *password) etc. for each well-known parameter name, but any
>> non-trivial program which has to care about connection parameters will
>> have to deal with un-specced parameters (since every CM in existence has
>> some bizarre protocol-specific parameters) so will wind up falling back
>> to tp_asv_…
>>     
>
> Yes, but explicit functions for the standard stuff would still make code
> smaller clearer and safer.
>   

True, they'd be nice on top of tp_asv_set_* . That said, most people
won't ever need to create connections directly in the flying car future
of the new AccountManager API, which is not yet a reality.

>> In related news, I have been investigating the list_all_protocols
>> example in telepathy-doc, and have found some race conditions in the
>> initialization of TpConnectionManager which means that got-info might
>> never (visibly) fire… This is probably the least well-tested area of the
>> client-side API, which is particularly unfortunate as it's one of the
>> first things you'd have to deal with to write a full Telepathy client
>> from scratch. :(
>>     
>
> Many thanks for investigating.
>
> In general, if it's not tested then it doesn't work.
>   

Of course. Most of this stuff is very well-tested (both in real
applications and in test suites), which is why this is particularly
unfortunate. :-)

Cheers,

-- 
Will


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
Url : http://lists.freedesktop.org/archives/telepathy/attachments/20081027/9c03fc3a/attachment.pgp