[Bug 71508] [1.0] simplify TpPresenceMixin

[bugzilla-daemon at freedesktop.org]

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

--- Comment #9 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
(In reply to comment #8)
> I think we can get one step further and remove
> tp_presence_status_spec_get_id().

It's basically there because the example C CMs, and the real C CMs, do
everything in terms of an enum. It's easier to say

    contact->presence = EXAMPLE_PRESENCE_STATUS_AVAILABLE;

than

    contact->presence = example_protocol_get_presences
()[EXAMPLE_PRESENCE_STATUS_AVAILABLE];

and it has less boilerplate and less diffstat than:

    contact->presence = example_protocol_get_presence_available ();

I'm tempted to make TpPresenceStatusSpec be a GObject, so it can have qdata or
a CM-specific subclass or something, and then CMs can do whatever they want to
do. The index is basically acting as "poor man's qdata" here.

> I don't know how other CMs implement that, but looking at our fake
> contacts-conn.c, it has 2 hashtables:
> 
> presence_statuses: TpHandle -> index of a TpPresenceStatusSpec
> presence_messages: TpHandle -> message string
> 
> Merging those is exactly what TpPresenceStatus is made for.

I sort of agree, but please look at some real CMs before being too sure about
that. For instance, Haze's internal data structure is a PurpleContact or
something, and Gabble and Salut's internal data structures ought to be some
sort of WockyContact really.

In recent mixins I have been leaning towards making the obvious path be "the
mixin is a 'view' of the real data, which is in CM-specific structures" because
the better your IM protocol library is, the closer to that you're going to be.

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