[Bug 29078] use TpBaseProtocol

[bugzilla-daemon at freedesktop.org]

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

--- Comment #2 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-07-16 05:26:55 PDT ---
(In reply to comment #1)
> +  /* FIXME: is it safe to pass a NULL account to prpl_info->account for all
> +   * prpls? If it is, we could do that to be more likely to normalize right */
> +  return g_strdup (purple_normalize (NULL, contact));
> 
> You mean ->normalize, not ->account. And, it seems to be, except for Zephyr
> (which will critical). A bunch of the other normalization functions have
> comments suggesting that it's not accidental that they work with account ==
> NULL. :)
> 
> So I think we should do that; or, make purple_normalize() do that. Your call.

purple_normalize() can't do that, because it doesn't know which prpl we're
dealing with (it'd normally get that from @account). My vote would be to add:

gchar *
purple_plugin_protocol_info_normalize (PurplePluginProtocolInfo *prpl,
    const char *contact)
{
    if (PURPLE_PROTOCOL_PLUGIN_HAS_FUNC (prpl, normalize))
    {
        return prpl->normalize (NULL, contact);
    }
    else
    {
        return purple_normalize (NULL, contact);
    }
}

and fix the Zephyr plugin in the same Pidgin release.

In the meantime, we could optionally do the same in Haze, and either assume
that nobody uses Zephyr or insert some sort of hack. I think purple_normalize
is good enough for now, though.

> This stuff with haze_foo_manager_append_channel_classes, all with identical
> implementations, suggests that that should live in tp-glib. Not clear exactly
> how, though...

Perhaps. The problem is that Protocol wants to enumerate all
possible-to-implement channel classes statelessly, whereas Requests wants to
enumerate all channel classes that will actually work, given a connected
Connection, and the TpChannelManager API was designed for the latter.

More precisely, what we want is:

* HazeProtocol has a list of TpChannelManager *classes*: HazeConnection's
create_channel_managers() will not create channel managers not chosen from that
list

* Each TpChannelManager has a new class-method (i.e. first parameter is
TpChannelManagerClass *, not TpChannelManager *) that returns a list of all
possible channel classes, which is a superset of the result of
foreach_channel_class()

I'll have a look at implementing that in tp-glib.

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