[Bug 27269] review and clean up TplContact public API

[bugzilla-daemon at freedesktop.org]

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

Simon McVittie <simon.mcvittie at collabora.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|API review: TplContact      |review and clean up
                   |                            |TplContact public API
                URL|http://git.collabora.co.uk/ |
                   |?p=user/cassidy/telepathy-l |
                   |ogger;a=shortlog;h=refs/hea |
                   |ds/contact-api-27269        |
             Status|NEW                         |ASSIGNED
           Keywords|patch                       |
         AssignedTo|simon.mcvittie at collabora.co |guillaume.desmottes at collabo
                   |.uk                         |ra.co.uk

--- Comment #12 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-05-28 06:33:14 PDT ---
TplContact is tied up in the TplLogEntry API, so to an extent they need to be
considered together.

Senders are always genuine contacts (in Telepathy terminology), either
TPL_CONTACT_USER or TPL_CONTACT_SELF.

The receiver isn't really a property of the log entry: I'd say that
conceptually, it's more like a property of the conversation. A given
conversation is directed to the TargetID of its channel, which can either be a
contact (self or remote), a named chatroom (as seen in XMPP/IRC), an ad-hoc
chatroom (as seen in MSN/Skype), or some other thing that hasn't been defined
yet.

It seems to me that there are basically three ways we could represent messages'
receivers:

1) Rename TplContact to something like TplEntity or TplTarget. A log entry has
a sender, a TplEntity whose type is SELF or USER, and a receiver, a TplEntity
of any type.

2) Get rid of non-contact functionality from TplContact, and turn the type into
a simple boolean, is_self. 1-1 messages have a non-NULL receiver contact. Other
messages have a NULL receiver contact; the receiving chatroom can be inferred
in some way from the message (via the chat ID if its type becomes
better-defined, perhaps).

3) Get rid of non-contact functionality from TplContact, and turn the type into
a simple boolean, is_self. Get rid of the receiver property too, and relate the
message to a first-class Conversation object, which either has a pointer to a
TplContact (called "target_contact" or something), or a way to get the chatroom
name.

(1) is the easiest, but is the one I like least. What would get_alias(),
get_avatar_token() mean for a chatroom?

Another question this API gives me is: what is the scope of a TplContact? It's
not clear to me which of these would typically be true:

* All my conversations with Cosimo represent him as the same TplContact.
get_alias(), get_avatar_token() return his most recent details; older details
are ignored.

* Each conversation with Cosimo represents him as a different TplContact.
get_alias(), get_avatar_token() return the most recent details from that
conversation. I have to use get_identifier() to relate the contacts to each
other.

* Each visually distinct version of Cosimo represents him as a different
TplContact, i.e. whenever get_alias() or get_avatar_token() changes from one
message to the next, the TplContact changes. I have to use get_identifier() to
relate the contacts to each other.

Why are the alias and the avatar token in the log? Is it basically a tiny
version of persistent contact storage (analogous to libfolks or osso-abook), to
be dropped in some future version?

The avatar token doesn't seem very useful when you can only get a cached avatar
via a TpContact - we'll probably have to add API to telepathy-glib to see
whether a cached avatar is still available, and if so, return them. This will
require the connection manager name and the protocol name (both derivable from
the TpAccount name), and can't be done for non-Telepathy avatars.

Perhaps a better way to do the avatar would be to keep the avatar token, CM
name and protocol name behind the scenes, and have:

    GFile *tpl_contact_get_avatar (TplContact *contact);

which can return NULL, and would be implemented in terms of new telepathy-glib
API, something like:

    GFile *tp_account_get_cached_avatar (TpAccount *account,
        const gchar *avatar_token);

> TplContact *tpl_contact_from_room_id (const gchar *chatroom_id);
> TplContact *tpl_contact_from_tp_contact (TpContact *contact);

Shouldn't these be internal?

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