[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 #9 from Jonny Lamb <jonny.lamb at collabora.co.uk>  2009-09-24 10:13:32 PST ---
(In reply to comment #4)
> Yes, AccountManager.DefaultPresence or some such would be a good addition. I'll
> do that.

I've added a #TpAccount:default-presence property. I guess you'd prefer it on
TpAccountManager instead then?

> > I pondered a bit more about the become_ready and i must say (assuming i'm
> > allowed to bikeshed a bit) i prefer prepare. As it the operation you call means
> > prepare these features on this object, like g_output_stream_write means write
> > these bytes to the output stream. become ready these features just doens't work 
> 
> If that's the colour you want your bike shed, then I think we should rename the
> entire "ready" concept to "prepared", which does make a certain amount of
> sense. This would also make it less confusing when we deprecate
> TpConnection::connection-ready.
> 
> Jonny: what do you think of this idea?

I renamed it from prepare, to become_ready, and back to prepare. You've hit
your quota for changing your mind, boys.

> > This doesn't make sense to me, is there any reason you ever want to know this ?
> > Either you want a feature to be available or not, i don't see how the knowledge
> > that something is preparing itself ever helps the user.
> 
> Perhaps that should be internal (or proxy-subclass.h), yeah. The distinction
> between the three sets is important, though, even if not all of them are public
> API - if an API works with readiness (or "preparedness") it should document
> exactly what it does/needs.
[snip]
> Could we leave it out, or make it library-internal (_tp_foo namespace and
> account{,-manager}-internal.h), until we decide whether it's useful?

Hmm, okay, so I'll make these internal?

> > > > void tp_account_refresh_properties (TpAccount *account);
> > > 
> > > Should never be needed... if the AM crashes, TpAccount should recover
> > > automatically when it notices the AM name come back, updating any 
> > > accounts that are still there and invalidating any accounts that turn 
> > > out to have disappeared(telepathy-qt4 implements this).
> > 
> > So does empathy, refresh_properties is basically private api for the Account
> > managers benefit, so that it can poke still existing accounts after a AM crash
> > to ensure they're still in sync. If we allow the TpAccount to be created
> > manually this is less benefitial indeed, althought it's slightly annoying that
> > all TpAccount objects need to watch the AM, verify they still exist etc etc. 

Hmm, does that mean that
http://git.collabora.co.uk/?p=user/jonny/telepathy-glib.git;a=commitdiff;h=fce7efce420e
is in error?


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