[Bug 296867]

[Simon McVittie]

(In reply to comment #91)
> Realization of the first three points would require adding a new interface
> to gabble. I imagine it as an extension of connection interface providing
> settings individually for every account. Would using gdbus codegen just
> like in case of the currently implemented otr channel be acceptable here?

You could make it go "next to" the Connection just like Xavier's code
produces an object "next to" the Channel, yes.

(Unfortunately, the fact that, in general, telepathy-glib uses the
deprecated dbus-glib instead of GDBus is not going to get fixed, unless
someone with a lot more time available than me picks it up. See the
various "Telepathy 1.0" bugs for details.)

> I
> suppose that adding these features would mean some major changes in the
> current implementation which is completely closed in the channel interface.

Making behind-the-scenes C function calls between the Connection and
Channel objects is fine.

> There are also things that need to be fixed as stated above:
> ...
> I understand that they have to be done first before introducing new changes?

Yes, I think that would be better than hoping they will be fixed later.

I consider those fixes to be merge blockers for these branches, because
I don't want to add an interop and security feature that, on closer
inspection, turns out to be non-interoperable or insecure :-)

-- 
You received this bug notification because you are a member of
Telepathy, which is subscribed to empathy in Ubuntu.
https://bugs.launchpad.net/bugs/296867

Title:
  empathy needs to support OTR encryption

To manage notifications about this bug go to:
https://bugs.launchpad.net/empathy/+bug/296867/+subscriptions