[Bug 29451] Too many asynchronous setup steps needed for basic usage

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-18 04:40:12 PDT ---
> (In reply to comment #4)
> Well, I added the separate signal to my plan, but I'm still not convinced the
> not-quite-ready-for-the-use-you-asked-for-yet Account is useful, because tp-qt4
> Account features are all semi-fast

Right, if you document very clearly that all Account features now and forever
must be at least semi-fast, then this is sufficient, and we don't have a
use-case for slow preparation.

I think there's value in having some features not be fast, though; the
as-yet-hypothetical TP_CONNECTION_FEATURE_CONTACT_LIST ought to wait until the
server has actually returned the initial contact list, which can apparently
take multiple minutes on shaky cellular connections.

It's case-by-case by class, really:

- on AM and Account, you're right that there's no reason why we'd have any slow
features, because Accounts are locally-stored; unless there are features that
are really shorthand for a Connection feature, in which case the below applies

- on Connection, telepathy-glib has a CONNECTED feature, mostly for historical
reasons (the old "ready" boolean was "too big"); but in any case it seems
useful to be able to wait for CONNECTED-and-a-bunch-of-features in a single
transaction. Contact lists ought to be a feature that makes round-trips,
probably, too.

- on Channel, I'm not sure

- on contacts, so far we've avoided slow features by design; the Alias feature
doesn't really mean "I have the alias", but "I've made some effort towards
getting the alias, and if I immediately had it to hand, I've returned it".

> > It's worth keeping in mind, but not necessarily as a/the primary goal.
> 
> The big-object-instance-specific-factories approach described above allows us
> to initially leave out the subclass specification but add it later on.

Yes. Good :-)

> > It's also safe for a telepathy-qt4 Client to have a flag for "don't invoke me
> > until the Connection is CONNECTED" (even though telepathy-qt4 doesn't normally
> > do this), because the Client knows whether it's useful on disconnected
> > Connections (most aren't).
> 
> Yeah, instead of having a FeatureConnected this we could allow specifying this
> just for the Client, with no effect on accessing the Connections through the
> AM.

Straw man: imagine that TpConnection didn't have the CONNECTED feature. Instead
of putting it in its feature set, TpBaseClient could have had:

/* must be called before _register() */
tp_base_client_require_connected_connection (TpBaseClient *);

You could do a Qt equivalent of that?

> > TP_CONNECTION_FEATURE_CONTACT_LIST_INFO
> >     Status/capability flags (CanChangeContactList, ContactListState etc.)
> >     which are always available after you have CONNECTED
> >     Implies TP_CONNECTION_FEATURE_CONNECTED
> > 
> > TP_CONNECTION_FEATURE_CONTACT_LIST
> >     The actual contact list, with TpContact objects (with ID, handle
> >     and subscription states only, at the moment), and change notification
> >     Implies TP_CONNECTION_FEATURE_CONNECTED and ...CONTACT_LIST_INFO, and
> >     also implies contact-list-state == TP_CONTACT_LIST_STATE_SUCCESS
> 
> I think currently tp-qt4 would go Ready when it has the Info and emit
> allKnownContactsChanged when the contacts are actually fetched. The clients
> need to listen for new contacts added anyway if eg. another client adds a
> contact.

Right. That somewhat brings us back to the multiple-transactions problem,
though: you wait for the features, but then you can't draw your contact chooser
until you have *also* had allKnownContactsChanged; but you can't just ignore
the preparation and rely on getting allKnownContactsChanged, because if the
contact list was already ready, you might wait forever?

Ideally, you want a single GAsyncResult/Tp::PendingOperation round-trip between
"I have a connection, how is it formed?" and "draw the contact chooser".
TP_CONNECTION_FEATURE_CONTACT_LIST as described there would be that single
round-trip, at the cost that it's a "slow feature" that might not work well.

Perhaps I should just assume that you won't want to wait for more than one
unrelated "slow feature", and special-case them. It could have API like this:

/**
 * equivalent to: tp_proxy_prepare_async (self, features) followed by
 * waiting for the contact list and waiting for them all to have the
 * desired features
 */
tp_connection_await_contact_list_async (TpConnection *, const GQuark
conn_features[], const TpContactFeature *contact_features)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.