(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 Ubuntu Bugs, which is subscribed to 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 -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
