[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 #27 from Jonny Lamb <jonny.lamb at collabora.co.uk>  2009-09-26 04:37:07 PST ---
(In reply to comment #20)
> Something I forgot to mention about the Connection stuff is that if we're
> making the TpConnection not an API guarantee, it'll need a property + getter
> pair for the Connection object path (which wouldn't be a bad idea anyway).
> 
> I'd be inclined to make the C API for that either return NULL or a real object
> path (as opposed to the raw D-Bus API, which is either "/" or a real object
> path).

At the time of writing, I've made _get_connection return a TpConnection. Sounds
good. As a result, this isn't particularly important right now, but would be
very trivial to add. Shall I add it now or just wait?

> get_{requested,actual,missing}_features still seem to be extern on both Account
> and AM. Indeed, I don't see an account-internal.h, which would be a
> prerequisite for making things internal - presumably you forgot to implement
> (or perhaps push) this?

I was just waiting a while to make sure people weren't going to change their
mind on this one. I've internalized them now.

> *_is_ready (should be _is_prepared now, surely?) are also reasonable candidates
> for this treatment, if they're not immediately needed.

I think _is_prepared (now renamed from _is_ready) is useful to have around.
Although one could easily call _prepare_async, it's sometimes really annoying
to have to make all your code asynchronous and you simply might not want to do
anything if a certain feature is not prepared. As Sjoerd pointed out, comment
#17 gives a use-case for _is_prepared.


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