[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 #14 from Olli Salli <ollisal at gmail.com> 2010-08-18 10:18:40 PDT ---
(In reply to comment #9)
> 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.

What about having an extra attribute for features "isReallySlow" - which could
then be used to filter out with a warning such features (currently none) when
setting them to be automatically readified in a factory?

> 
> 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
> 

If we are able to specify Connection features on the AccountManager API
directly, we don't need pass-through features -> all Account and AM features
will be fetching from local store only.

> - 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

We could make these slowFeatures then, if the need for any emerges.

> 
> - 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".
> 

I think this is sensible - the application needs to listen for any changes the
remote contact makes anyway, so it can listen to actually having properly
fetched the data using the same mechanism at zero cost.

> 
> 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?

Exactly.

> 
> 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?

allKnownContactsChanged is the same signal that's emitted if some other app
adds a contact, or a remote contact adds you (in addition to the presence
blahblah requested signals), so the app needs to listen to it to lazily update
new contacts to view anyway. The use I'm suggesting is:

1) connect to allKnownContactsChanged
2) get whatever currently is in allKnownContacts (what the CM & tp-qt4 have
been able to report up to that moment, which is usually ~everything, but can be
~zero if the contacts slowly download from the server)
3) show the contacts chooser / friend presence list / contact list editor /
whatever
4) if allKnownContactsChanged is emitted, update the widget accordingly

Isn't this a quite common pattern? Like, get the pending messages, or don't get
any, but in either case get any new messages by a signal? So, I'm not proposing
the application always wants for X allKnownContactsChanged invocations, or any,
before displaying the roster.

> 
> 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.

I'm trying for "I have Telepathy" (AM really) - when can I show and do
whatever's interesting to my application at all of its levels, and can continue
doing so when events happen / new objects appear?

That said, we can still add such slow features if we filter them out (force
flag?) appropriately for the (often) app-wide factories.

> 
> 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)

Maybe. We could do this in tp-qt4 easily using the PendingComposite class if
the slow features are PendingOperations.

-- 
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.