Bug 36604

(In reply to comment #0)
> If there was some kind of TP_ACCOUNT_FEATURE_CONNECTION_CONNECTED or similar
> features on a TpAccount which could prepare the TpConnection in a TpAccount if
> it was there that would be really useful as I would only have to prepare the
> TpAccount once and when that returned I'd already have my connection set up as
> I wanted it!

Wow, that's all one sentence! Go me!

Another way to do this, which I think I'd prefer, would be:

    void tp_account_prepare_connection_async (TpAccount *self,
        const GQuark *account_features,
        const GQuark *connection_features,
        the usual async goo);
    gboolean tp_account_prepare_connection_finish (TpAccount *self,
        TpConnection **,
        GError **);

Either way, it's worth documenting very clearly that this isn't, in itself, sufficient to make the account go online: you have to set a requested presence too. (Maybe there should be a version that takes 3 extra arguments representing the RequestedPresence, or a version that copies the AutomaticPresence to the RequestedPresence if it isn't already "something online-looking".)

If ChangingPresence goes from true to false with no Connection, any pending tp_account_prepare_connection_async calls should probably also fail, with the ConnectionError as error.

(In reply to comment #2)
> Another way to do this, which I think I'd prefer, would be:
> 
>     void tp_account_prepare_connection_async (TpAccount *self,
>         const GQuark *account_features,
>         const GQuark *connection_features,
>         the usual async goo);
>     gboolean tp_account_prepare_connection_finish (TpAccount *self,
>         TpConnection **,
>         GError **);
> 
> Either way, it's worth documenting very clearly that this isn't, in itself,
> sufficient to make the account go online: you have to set a requested presence
> too. (Maybe there should be a version that takes 3 extra arguments representing
> the RequestedPresence, or a version that copies the AutomaticPresence to the
> RequestedPresence if it isn't already "something online-looking".)

This would help in the initial “Okay I have the account now I want the connection” case but it doesn't help you monitor the coming and going of a connection on an existing account.

Could we have a TpAccount::connection-prepared signal whose detail is the feature quark you're interested in? :D

I've actually did similar as part of bug #26205: http://cgit.collabora.com/git/user/xclaesse/telepathy-glib.git/log/?h=contact-list

The idea is that I can set desired contact features on the connection, desired connection+contact features on the account and desired account+connection+contact features on the AM, like that a single async method on the AM and *everything* is ready to go.

This part is already merged into master. preparing TP_ACCOUNT_FEATURE_CONNECTION on your TpAccount will ensure that the TpConnection object exposed will always be ready.