|Summary:||[next] rethink TpContact creation|
|Product:||Telepathy||Reporter:||Xavier Claessens <xclaesse>|
|Component:||tp-glib||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||RESOLVED DUPLICATE||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|i915 platform:||i915 features:|
|Bug Depends on:|
Description Xavier Claessens 2012-05-02 02:52:11 UTC
Atm, to get a TpContact we have those functions: tp_connection_get_contacts_by_handle(): - I think CONTACT TpHandle must totally disappear from our API, and this function should be killed. I think in general high-level APIs should expose TpContact objects. At least spec should always give handle+id and so the recommended way to get a TpContact is tp_client_factory_ensure_contact() + eventually upgrade. Note that 'next' already make immortal handles mandatory. tp_connection_get_contacts_by_id(): - It should be proper _async(). - Should use GetContactAttributesByID (bug #30874) for massive simplification and single round-trip. tp_connection_upgrade_contacts(): - It should be proper _async(). tp_connection_dup_contact_if_possible(): - Since we are making immortal handles mandatory, it is always possible to dup a contact with handle+id. In that case just use tp_client_factory_ensure_contact() - As said above, if you don't have id+handle, you should just never get a TpContact. - IIRC there are legitimate uses internally, when the spec gives only an handle but we are supposed to already have the TpContact (like removed members in group). So I suggest keeping some form of this but internal only. One thing I would like is to ensure that at any moment, even internally, a TpContact has both id+handle. Making those 2 construct-only mandatory properties.