[Bug 28037] TpContact should have helper API to set alias

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-05-10 02:19:35 PDT ---
The concept seems reasonable, but I'm a little worried that this is going to
either need deprecating, or have a name that's not consistent with the rest of
the API, when we implement the ContactList and Names D-Bus API shortly.

The current plan is to solve the "is it a nickname or user-assigned?" problem,
Bug #14540, by introducing a Connection.Interface.Names with separate contact
attributes for remote-contact-assigned nickname, local-user-assigned "local
alias"/"pet name", and abbreviated identifier (e.g. just the part of a JID
before the @).

See Bug #21787, although I might split the implementation of Names out of that
bug into Bug #14540. Your comments and/or help on either or both interfaces
would be appreciated.

I think the semantics of this method should be "store a name for the contact",
defined in a way that currently means SetAliases, but can become SetLocalAlias
(or whatever) when we introduce it. That makes the naming tricky, though,
because we're still not sure what to call the alias assigned by the local user
("local alias" is the current proposal), so can we defer this a little until
Names has settled down enough that we know what to call the method?

(I plan to work on ContactList and Names while on trains later today.)

Looking at the implementation:

> +    TpConnectionAliasFlags alias_flags;

You don't seem to use this? Remove it; we can add retrieval of the Names
information as part of the development of that interface.

> + * @self's #TpConnection must be ready (#TpConnection:connection-ready
> + *  must be %TRUE) and not invalidated.

You don't need to return_if_fail that the connection is ready: if the
connection was able to create a contact, then it must have been CONNECTED at
some stage (only CONNECTED connections can have valid handles, and TpContact
always has a valid handle).

If you did need to make this assertion, new code should be documented in terms
of the features (in this case it'd be TP_CONNECTION_FEATURE_CONNECTED, which is
in fact equivalent to connection-ready).

An invalidated connection shouldn't be a return_if_fail: the whole point of the
invalidation mechanism is to fail gracefully on dead objects, without
criticalling and hence requiring a boilerplate check in advance like dbus-glib
does. Just add a regression test that tries it on a dead connection, and makes
sure the async op fails (making a tp_cli D-Bus call on an invalidated
connection fails with the invalidation error, so the minimal implementation is
to do nothing special).

Talking of which, where's the regression test? :-)

-- 
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.