[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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|tp-qt4                      |general
                 CC|                            |guillaume.desmottes at collabo
                   |                            |ra.co.uk,
                   |                            |xclaesse at gmail.com
         Depends on|                            |29528, 29529

--- Comment #1 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-13 04:00:01 PDT ---
Reassigning this to the general component since it affects telepathy-glib too.

(In reply to comment #0)
>  * allow specifying which Account features should be ready in any Account an
> AccountManager gives you, and make AccountManager make them ready before
> signaling accountCreated() and signaling itself being ready in the initial
> accounts download on AM::becomeReady() -> no need to do Account::becomeReady()
> on accounts from the AM

One possible model would be to signal the "creation" as soon as possible, or as
soon as Core is ready, and then signal *again* when the desired features are
ready.

>  * allow specifying which Connection features (on which Connection subclass)
> should be made ready before signaling Account::haveConnectionChanged(true) ->
> no need to do Connection::becomeReady() on whatever Account::connection() gives

This is a particularly nasty case. Some modules want to see a Connection as
soon as it pops up, others don't want to care until the CONNECTED feature is
ready; we can't just wait for the upper bound, in case the Connection *can't*
become connected until someone has interacted with it. Consider pre-connection
TLS channels, popping up to ask "this certificate looks suspicious, is it OK?",
or pre-connection authentication channels, popping up to ask for your password
- it's very important that their Handlers can run before CONNECTED.

>  * allow specifying which Contact features should always be ready for a contact
> signaled as having joined a Channel (this should be documented as dangerous if
> used with too many features - if the contact in question leaves the channel
> before we finish introspecting every feature, the operation may fail and we
> won't necessarily even know who it was)

This is a danger, yes. I'd rather have the API make this situation impossible
when used with a sufficiently good connection manager - for instance, the
Contact could just appear anyway, with its alias/avatar/hat colour missing, as
long as it has its handle and identifier.

(This is tied up in considerations about handle lifetimes, 

>  * allow specifying which Channel features are always interesting for any given
> channel class, so that Channels given to you when you're a Client or when you
> request one in general are always ready with the desired features (requires
> extending ChannelFactory to accept dynamically overriding which Channel
> subtypes to construct, and which features to begin making ready for a given set
> of immutable properties making up the channel class)
> 
> I'll file the corresponding sub-bugs as dependencies when I have time to do so.
> Suggestions, especially turning in more superfluous setup step suspects kindly
> welcome. The suggestions above can be implemented in a backwards-compatible
> fashion, but we should identify beneficial candidates for an API/ABI break too.
> 
> The basic assumption above is that each application has a basic set of features
> they're always interested in, and will want for every object. Stuff that an
> application is only potentially interested in (menu option to show eg. avatars
> for chat participants, the user opening a "more gory details on your friend"
> expander widget, and so on) can always be "upgraded" afterwards on top of the
> base set in the current fashion (becomeReady() with more features,
> upgradeContacts()). Also, in more sophisticated applications, whatever can be
> lazily updated to the view, should be lazily updated after an upgrade operation
> finishes, and should be documented as the recommended action in tp-qt4 docs.
> 
> One final point is - whatever we do, this shouldn't counteract trying to avoid
> extra D-Bus state download and signal connections to uninteresting information
> (forcing Features on etc). Also, we shouldn't hamper subclassability. Even if
> Account constructs Connection objects for you you should be able to specify the
> Connection subclass and desired Connection features, etc. This could be
> accomplished in general using a factory pattern, where you specify a factory
> function returning the desired subclass and the features to always make ready
> in constructed objects.
> 
> To keep the factories simple, they should only begin the process of making the
> desired Features ready (and do the other misc manipulation on the constructed
> object). The constructed object should be returned immediately. The object (eg.
> AM) which requested constructing the object (the Account) should then wait for
> the object to get ready, with no further interaction with the factory for that
> object.

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