[Bug 27948] TpBaseConnection: support AddClientInterest, RemoveClientInterest

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-06-08 08:05:44 PDT ---
Things that still need review are:

* the spec, on Bug #27835
* this GObject type-hierarchy voodoo:

(In reply to comment #3)
> (In reply to comment #2)
> > I'm not sure to properly understand code in _constructor iterating over types.
> 
> Its effect is:
> 
>     foreach (interface @iter in client_interest_interfaces)
>       {
>         ensure that priv->client_interests contains an empty map for @iter
>       }
> 
> However, because you can have a hierarchy, like this hypothetical situation:
> 
>     GObject
>     \--- TpBaseConnection (c_i_i is assumed to be empty)
>          \--- HazeConnection (c_i_i = [NICKNAMES])
>               \--- HazeMSNConnection (c_i_i = [MAIL_NOTIFICATION])
> 
> we need to walk the hierarchy from HazeMSNConnection (inclusive) up to
> TpBaseConnection (exclusive), and iterate all of the current class's
> client_interest_interfaces (which I'll abbreviate c_i_i).
> 
> The alternative would be to require HazeMSNConnection to have c_i_i =
> [NICKNAMES, MAIL_NOTIFICATION], which isn't particularly onerous, but makes it
> more difficult to introduce a new interface that has a client interest in a
> superclass and make it work automagically in subclasses - the subclasses would
> either have to copy the parent's c_i_i manually, which is irritating, or make
> assumptions about the parent's c_i_i, which will break additions of
> functionality in superclasses.
> 
> I might at some point add a non-empty c_i_i to TpBaseConnection, if we come up
> with API that requires it on all connections (I've wondered about doing this as
> a solution to the handle-reffing problem).

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