[Bug 26205] High-level API for ContactLists

[bugzilla-daemon at freedesktop.org]

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

--- Comment #10 from Xavier Claessens <xclaesse at gmail.com> 2011-06-02 07:51:44 PDT ---
(In reply to comment #8)
> (In reply to comment #7)
> > 1) a feature on TpConnection telling to create TpContact for all known
> > contacts, with a method to get them all, and a signal telling those
> > added/removed.
> 
> s/all known contacts/all contacts on the contact list/
> 
> (yes, there is a distinction - consider blocked contacts)

Right, that's the name in tpqt4, probably because of 'known' list (now renamed
to 'stored'). Maybe I should just rename to list<TpContact>
tp_connection_get_contact_list() ?

> This shouldn't imply "wait til the contact list is ready" because that might
> never terminate (consider MSN when the contact list server has fallen over -
> you can still talk to people, and having everything wait for this desired
> feature to be ready wouldn't be beneficial.)

My current implementation waits for connected and status success. But I agree
this might not be correct. Maybe it should wait if state is WAITING, and stop
on FAILURE or SUCCESS. Once state goes to SUCCESS or FAILURE, I assume it can't
change anymore, can it?

> If getting the contact list has failed, there should be an accessor for the
> error we saw last time we tried?

Something like that?
TpContactListState tp_connection_get_contact_list_state(connection, &error); 

> The state property added by your branch should probably delay moving to
> Succeeded until we have actually downloaded the complete list of contacts, if
> we're trying to do that?

I'm considering removing the FEATURE_CONTACT_LIST and keep only
FEATURE_ALL_KNOWN_CONTACTS that would do both. and actually that feature could
then be renamed to FEATURE_CONTACT_LIST? I agree there is probably no interest
in having contact list properties without actually having contacts.

> > 2) a way to define on TpConnection the features we want to be prepared on all
> > known contacts before exposing them
> 
> "features we want to be prepared on new contacts before signalling them"?
> 
> Or we could just say "you will get at least subscription states, everything
> else you have to wait for".

GetContactListAttributes allows giving all the features we want, to fetch
everything at once. That would be faster than fetching only subscription state,
then let user upgrade contacts again, no? What about my proposal in comment #9
?

> > 3) tp_connection_*_async(TpConnection *, array<TpContact>) and
> > tp_contact_*_async() for all those methods:
> > 
> > RequestSubscription
> > AuthorizePublication
> > RemoveContacts
> > Unsubscribe
> > Unpublish
> 
> I think this is more important than (2).
> 
> While you're writing boilerplate you might also want block, unblock and
> block-and-report-abuse (the Blocking interface).

Still on todo-list. There are also AddToGroup, etc. I didn't start with that
because they are just plain wrapper around the dbus call, nothing smart is
needed there. Boring copy-pasting :D

> Regarding your branch:
> 
> > + "ContactList can change", "Whether the contact list can change",
> 
> No, it might be able to change even though *we* can't change it (consider
> Facebook).

Doc wording needs love everywhere. Suggestions for that one? :)

> > + * TP_CONNECTION_FEATURE_CONTACT_LIST:
> 
> I'm a bit wary about using this feature name for something that isn't your
> stage (1) above. If I activate the "contact list" feature, surely I should have
> a list of contacts?
> 
> You could either rename this to CONTACT_LIST_PROPERTIES, or decide that it will
> imply "contact list will be present as a list of TpContact, if the CM-side
> state allows it" (i.e. combine it with (1)).

I've replied this above, I agree with you.

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