[Bug 21787] Connection.Interface.ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #34 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-06-28 07:33:47 PDT ---
(In reply to comment #32)
> This will require special work for bindings

Our generated bindings in telepathy-glib have the timeout as a parameter, so
they're OK already. However, telepathy-qt4 doesn't; I consider this to be a
telepathy-qt4 bug (I've filed Bug #28797) whose fix is blocked by a QtDBus bug
(<http://bugreports.qt.nokia.com/browse/QTBUG-11775>).

> Also, a
> good value for such a timeout would be the maximum of practical sync time
> limits on an unknown set of protocols. This is unmanageable.

I think the timeout is a UI decision. For how long is it acceptable for your UI
to display a "please wait" spinner before giving up in disgust - a minute, an
hour, 24 hours? However long that is, that's the timeout you should have.

> Maybe a property/signal pair could be added so that clients could wait on the
> signal, and know that GCLA will return empty if called while contact list
> synchronization is pending?

I think a boolean property with change notification could be a good idea too,
though. The change notification could be implicit (any ContactsChanged,
GroupsChanged, etc. signal implicitly indicates the transition to
ContactListRetrieved=TRUE), or explicit.

(In reply to comment #33)
> (In reply to comment #32)
> > Maybe a property/signal pair could be added
> 
> Also useful to expose the state when contact list retrieval fails.

Is your idea that this is state-recovery, something like this?

property ContactListFailure: s
    The D-Bus error name with which retrieval of the contact list failed,
    or the empty string if retrieval succeeded or is still in progress

I find it more natural for the data model to be that if you care about the
contact list, you call RequestContactList. If it takes a while, you can display
a "please wait" indication or something, knowing that it's still in progress.
When you eventually get your reply, it's either an error or success; if you
call RequestContactList when the attempt to download the contact list has
already finished, you get the same cached error or success.

(Having said that, TpBaseContactList doesn't yet allow subclasses to signal
that retrieval of the contact list failed, except by disconnecting the
Connection; I'll put that on my to-do list for telepathy-glib, but it's not
directly relevant to the spec.)

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