[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 #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-08-13 04:14:08 PDT ---
Urgh, pressed [commit] too soon. More:

>  * 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, Bug #23155.)

>  * 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 don't think the precise thing you're suggesting here is quite the right
approach, but it's close. I've been thinking about a similar case in
telepathy-glib, and was plotting giving each TpBaseClient an optional
ChannelFactory, so instead of setting things up as library-global state (which
is inherently dangerous if you have uncooperative modules), you set things up
per TpBaseClient and rely on everything that shares TpBaseClient being suitably
cooperative.

(Tp::AbstractClient would be your equivalent; Tp::ClientRegistry is not.)

> 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 is tricky if you encourage a pattern in which the whole process shares an
AccountManager pseudo-singleton (really one AccountManager per D-Bus
connection), which is something we probably do want, because sharing an
AccountManager means you share Accounts, which means you share Connections,
which means you can safely share Contacts.

Perhaps the rules should be "specifying a subclass factory on the
pseudo-singleton AccountManager is an error" and "if you want to get given
subclasses automatically, you have to operate in your own little world,
starting from your own AccountManager".

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