[Telepathy] Some more tp-glib feedback

[Simon McVittie]

On Thu, 29 Mar 2007 at 19:27:20 +0200, Sjoerd Simons wrote:
> * It's not documented that get_unique_connection_name may be NULL

Will fix.

> * tp_handle_ref has changed to be void.. Can we assume it shouts when you try
>   to ref an invalid handle ? I used the return value to assert a handle was 
>   valid while in the channel constructors.

Yes, it is expected to assert (well, g_return_if_fail).

> * Prop protocol of base-connection is used internally in contrast to what's
>   stated in the doc..  It's even mandatory !!

"Unused internally" was misleading; I believe it was meant to mean "we
only use it to reply to GetProtocol". It's become untrue in any case, we
use it for the object path and bus name too.

> * start_connecting always sets connecting after start_connecting.. Maybe we
>   should set it to connecting just before calling start_connecting? So we can 
>   handle CM's that don't (have) to connect async.
>
>   But that way if start connecting failed we would have -> connecting ->
>   disconnected signals during the Connect() call?

Clients probably ought to handle that.

Or, perhaps the base class should set CONNECTING afterwards, or
DISCONNECTED on failure, but only if it's changing the state from NEW? That
way start_connecting could set CONNECTED (or DISCONNECTED) if it wanted to.

Hmm... at the moment we guarantee that the state will pass through
CONNECTING, so we always call channel factory callbacks etc. for it. We
should probably preserve that invariant too.

Setting CONNECTING before start_connecting runs (after verifying that
at least Gabble and tp-sofiasip will behave correctly with that re-ordering)
seems the sanest thing to do.

> * Calling TP_SVC_CHANNEL_INTERFACE_GROUP_CLASS on a Objectclass implementing 
>   the interface asserts an invalid cast. Shouldn't that work or am i doing 
>   something silly here :) 

I think that ought to work. I'll check.

	Simon