[Bug 49215] Move chat state to TpTextChannel

[bugzilla-daemon at freedesktop.org]

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

--- Comment #8 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-04-30 05:43:44 PDT ---
> +TpMessageMixingSetChatStateImpl

"Mixin" not "Mixing".

> + g_return_if_fail (state < NUM_TP_CHANNEL_CHAT_STATES);

TP_NUM in new code, please (this is not the only instance, please grep).

> + g_hash_table_insert (mixin->priv->chat_states,
> + GUINT_TO_POINTER (member),
> + GUINT_TO_POINTER (state));

Please remove it if it's INACTIVE, like Gabble does, since that's "the default
state". Have you tried porting Gabble 0.17 to this? I would rather not add this
functionality without a proof-of-concept of a CM still passing its tests.

There should be a way for the CM to tell the mixin "this contact has gone away,
remove them from your hash table". Otherwise, a chatroom will build up a big
hash table over time: everyone who has ever been a member will be in the hash
table (with chat state GONE, if the CM is not broken).

I think Gabble might actually treat both INACTIVE and GONE as "emit signal and
remove from hash table", which seems reasonable.

> + * TpMessageMixingSetChatStateImpl:
...
> + * Signature of a virtual method which may be implemented to allow messages
> + * to be sent. It must arrange for tp_message_mixin_sent() to be called when
> + * the message has submitted or when message submission has failed.

This text does not describe this method.

Why would this method ever fail, other than InvalidArgument? (NetworkError, I
suppose, and telepathy-spec also says NotAvailable, but I'm not entirely sure
why).

If it fails, should this method fail synchronously or asynchronously?

+ /* I no func is set, then subclass is supposed to call

"If no function".

I think this should go in the TpProxyFeature docs, perhaps this:

@prepare_async: if not %NULL, called when preparing the feature is requested.
 May be %NULL for features whose preparation starts automatically (for
 instance from the proxy's #GObjectClass.constructed virtual method);
 if so, the subclass is still expected to call FIXME when the feature
 has been prepared.

However, the "FIXME" there still needs replacing... because out-of-tree proxies
still can't usefully add features, because the ability to say "it worked!" is
still internal-only API! I'll (re)open a bug.

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