[Bug 14540] Names interface - Aliasing replacement with separate nickname, local alias etc.

[bugzilla-daemon at freedesktop.org]

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

--- Comment #42 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Regarding this bit in the spec:

> To make it easier to deal with such protocols, if clients set
> metadata on a contact who is not in the required state, the
> Connection MUST cache the metadata for the duration of the session.
> If clients request the attributes of that contact after the
> appropriate "set" method has returned successfully, the Connection
> MUST return the new (cached) value. If the contact is later placed
> in the required state to store metadata (for instance, if subscription
> to the contact's presence is requested, on a protocol like MSN where
> the alias has storage type Subscribed_Or_Pending), the connection
> MUST store the cached metadata at that time.

I'm starting to think the mixin shouldn't try to ensure this: on a CM where
this is significant, the CM should compensate.

Haze is such a CM, so it's another useful target for prototyping - it has
something resembling TP_CONTACT_METADATA_STORAGE_TYPE_SUBSCRIBED (or at least,
it only stores aliases for "buddies" on our contact list, and it represents
those as subscribe = TP_SUBSCRIPTION_STATE_YES because it can't know any
better). At the moment, setting these contacts' aliases just fails, but we
could make it just signal a successful change for them (storing the alias in
TpNamesMixin), and copy from TpNamesMixin to the new buddy whenever it adds a
buddy.

I also wonder whether the mixin should be a pure "view" of data stored by the
CM's "model", and not store anything at all itself? That would mean it would
grow these methods:

    TpContactMetadataStorageType (*get_alias_storage) (TpBaseConnection *);
    TpNamesFlags (*get_names_flags) (TpBaseConnection *);
    gchar *(*dup_contact_local_alias) (TpBaseConnection *, TpHandle);
    gchar *(*dup_contact_nickname) (TpBaseConnection *, TpHandle);

and stop needing to store any data of its own. In practice, I suspect most
(all?) of our CMs are going to have a "model" that could be used for this: are
we gaining anything by duplicating it in the mixin?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.