[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 #4 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-17 07:32:24 PDT ---
(In reply to comment #3)
>  b) If application code wants more Account features than just Core (and
> possibly Capabilities), it needs to call becomeReady() on all of the Accounts,
> one by one, including any new ones from the newAccount() signal, and wait for
> the operation to finish

There's a tension between this, and wanting new Accounts to pop up as soon as
possible because it's signalling an event that, really, already happened.
Perhaps we want two signals, newAccount and newlyReadyAccount...

>  d) One can't specify the subclass of Account to construct in any case - even
> by subclassing AccountManager itself, actually. Subclassability was one of the
> original design goals for tp-qt4, but tbh I'm not sure if ever really cared
> about it - do we?

It's worth keeping in mind, but not necessarily as a/the primary goal.

>  - maybe it's actually: In AM, use whatever features you recognize, otherwise
> pass them to contained objects, and ditto for them

I'm not sure I like this meme: it makes it impossible to warn API users if they
supplied a Feature that makes no sense, and will have no effect. Silent failure
to act considered unhelpful :-)

>  - if the application hasn't requested and made ready a Connection using the
> Account in question yet, one still needs to make Connections ready in the
> application when doing channel handling (because it'll be newly created, or
> made ready on a bus-wide singleton with some default set of features (core), if
> there has been time to do so). This will probably happen often in handlers in
> non-monolithic applications, where the application (eg. a tube client) is only
> started and begins introspecting objects by service activation on the handler
> method.

Can we approach this from another angle? In a Client, don't call the
user-supplied HandleChannels, ObserveChannels or AddDispatchOperation callback
(vmethod? slot? whatever this is in Qt-land) until certain features are ready.

This solves the problem for every feature except Contact features in every app
that is only a Client, which I think will actually cover a lot of practical
use-cases, including all Tubes apps (which, long-term, we hope will be the
widest class of application).

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

It doesn't solve anything for apps that start from the AccountManager and work
downwards - account management UIs, status choosers, contact lists, and that
sort of "furniture" - but it's a start.

> Another approach 2), formalizing on the hand-waving I did with Andre last week
> and somewhat inscribed in the bug description is "object factories"

This seems like something we eventually want for subclassability, even if we
don't want it for feature preparation.

>  - we can make the factory instance / its settings either settable on a
> specific AccountManager, bus-connection globals or library globals

No library globals, please; that breaks the case of two unrelated plugins in a
non-Telepathy-aware plugin host (e.g. Maemo 5 status menu, gnome-panel, GEdit),
each of which wants to use Telepathy and subclass stuff. Attaching a factory to
an AccountManager instance could be a good way, though?

> If we make it somehow possible to specify the AccountManager
> instance to co-operate with on ClientRegistrar / the Adaptors (AbstractClient*
> is just a thin base class with no actual functionality!!!), we don't need a
> (bus-wide) singleton AM or factories to enable constructing Accounts /
> Connections with the desired factory settings.

I do like this. With hindsight, we should have probably made TpBaseClient's
constructor take a TpAccountManager, not a TpDBusDaemon, so that it can behave
similarly; I'll sort that out.

> This kind of link-up would also
> allow the Account convenience channel request methods to be improved to allow
> waiting for the requested channel to arrive, bypassing the usual handling
> mechanism.

This is a Qt equivalent of Bug #13422
(tp_account_channel_request_create_and_handle_async()), achieved by creating a
Handler behind the scenes and making it preferred, and it's probably worth
using a similar API:

http://telepathy.freedesktop.org/doc/telepathy-glib/telepathy-glib-account-channel-request.html

What you already have is equivalent to Bug #29456,
tp_account_channel_request_create_async().

> Caveats:
>  - if some part of the application wants to access Accounts before all of their
> features some other part of the application requested are ready, we must add
> another "giveMeAccountsEvenIfTheyAren'tReady" feature - or more logically,
> instead add AM::FeatureWaitForAccountsToBeReady which would be specified by
> default, leading to the [1] behavior described above, but can be left out, such
> that AM::becomeReady() will then return for that request before the accounts
> are ready - currently Core is always waited for, maybe this is a suitable
> middle-ground

Or, modules that only want to care about connected accounts can listen for
accountConnected instead of accountAdded?

>  - if a feature that only becomes ready when a connection is Connected is set
> to be guaranteedly ready on a Connection, this makes not-yet-connected
> Connections invisible, which makes for example handling authentication channels
> impossible as Simon pointed out in the previous comment.

Specifying features per (TpBase|Tp::Abstract)Client solves this: if you handle
authentication channels in your TpBaseClient, and you demand
TP_CONNECTION_FEATURE_CONNECTED, then you're silly.

> Actually, there are no
> such features on Tp::Connection - all features can be ready in any connection
> state, but are re-introspected when the state changes, and signaling the state
> change always waits for all previously requested features to be ready. (So we
> actually have had a guarantee somewhat resembling the ones I'm suggesting here
> for a long time - whenever statusChanged is emitted, any features previously
> requested are ready for the new status)

Indeed, telepathy-glib features and telepathy-qt4 features don't correspond
1:1.

I'm a bit wary of the telepathy-qt4 design at the moment, because I've been
investigating ContactList API for telepathy-glib. The contact list can be
downloaded asynchronously after CONNECTED, can take time to download (in XMPP,
multiple-minute lag is apparently entirely possible), and not signalling
StatusChanged(CONNECTED) until the contact list has been retrieved, because a
module over there -> asked for it before connecting, doesn't seem entirely
desirable...

The sketch I have at the moment is:

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 haven't done anything about contact features yet. I was wondering whether to
have a list of features to which you can only add (asynchronously) and never
remove; after the async addition has finished, each TpContact on the contact
list has all the features, and subsequently-added contacts aren't announced
until they too have all of those features.

(This only works because all the contact features are "fast", though...)

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