I'd be interested implementing this to simplify empathy-auth-client's code.

Also, if we are going to support the 'password' parameter in next it would be
good to have more helper code in tp-glib.

A sensible name for the TpChannel sub-class could be TpServerAuthenticationChannel, or maybe TpServerAuthChannel?

As stated in the documentation of
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html
this API could, in theory, be implemented on a different kind of channel (not
a Type.ServerAuthentication). Should I then implement the SASL API on top of
TpChannel instead of TpServerAuthenticationChannel?

I implemented this in http://cgit.collabora.com/git/user/cassidy/telepathy-glib/log/?h=sasl-41037

I also ported Empathy http://cgit.collabora.com/git/user/cassidy/empathy/log/?h=sasl-api
and Phoenix http://cgit.collabora.com/git/user/cassidy/telepathy-phoenix.git/log/?h=auth (blocked by introspection bugs).

Also, I'm wondering if it would make sense to have an higher level API taking care of watching the SASL status and calling AcceptSasl() or AbortSasl() directly. Both Empathy and Phoenix are doing it themself.

I would include empathy-sasl-mechanisms.c

(In reply to comment #3)
> I would include empathy-sasl-mechanisms.c

Ideally, the vendor specific code should be in the CM, see bug #37376

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-glib/issues/71.