[Bug 24061] TpAccount, TpAccountManager: add convenience API similar to libempathy's

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=24061





--- Comment #33 from Sjoerd Simons <sjoerd at luon.net>  2009-09-28 02:43:00 PST ---
(In reply to comment #32)
> (In reply to comment #31)
> > * MC restart from Comment #21 (still under discussion)
> 
> Removing this behaviour or making it opt-in later would not *technically* be an
> API break, I suppose, so we could release with it if it's the only blocker.

I'm happy to have a tp_account_manager_enable_restart for now, if we change our
minds making it a dummy and decrecating it won't hurt anyway.

TBH i'm more concerned about the channel dispatcher then the Am, it just
happens that both are the same currently

> > > * everything from Comment #29 (new)
>
> I do think these need addressing and are merge blockers.

To summarize:
  * instead of a created and deleted signal have:
     * A account-removed signal matching the one on D-Bus
     * an account-validity-changed signal matching the one on D-Bus as well
  * fix the implementation issue that smcv noticed
  * rename get_accounts to _get_valid_accounts
  * related to that, remove accounts from the when they are no longer valid or
filter them out in the  
    _get_valid_accounts call (latter is probably more future-proof)

> > * removal of the TpAccount:connection property (on which I'm prepared to be
> > overruled if you and Sjoerd both think having a lazily-allocated property value
> > isn't weird)
>
> Like I said, this is more "this is weird and may be unnecessary" rather than
> "this is harmful".

>From my perspective, it being lazily allocated is an implementation details of
the TpAccount
implementation, not something the API user would care about. 


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