Changes between Version 33 and Version 34 of mmcco

Timestamp:

Jun 22, 2015, 9:58:13 PM (9 years ago)

Author:

mmcco

Comment:

add real-time text section

mmcco

@@ -27 +27 @@
 
 == Clean-up ideas ==
-* Remove the Crazy Chat plugin (#16667) and Yahoo! Japan (#15906)
+* ~~Remove the Crazy Chat plugin (#16667)~~
+* ~~Remove Yahoo! Japan (#15906)~~
 * We have 344 `#if 0` blocks in the code base - are all of them still relevant and necessary?
 * The IM conversation API (found in `libpurple/conversationtypes.h`) consists of two core functions, two icon related functions, and eleven typing-status-related functions. It seems like the typing status functionality could be condensed a lot, or that "API" could be defined to something more useful/broad.
@@ -116 +117 @@
 
 There are third-party tools that can create what are effectively statically linked binaries using the `LD_PRELOAD` environment variable. These could be useful for creating a testing binary for distribution, but I haven't had the need for that.
+
+== Real-time text ==
+
+Real-time text (RTT) is a cool feature. It's generally useful, and it's particularly great for deaf people who want to better emulate verbal conversation. For more information on why it's useful, [http://www.realtimetext.org/ RealTimeText.org]
+
+I've tried adding it as specified in [https://xmpp.org/extensions/xep-0301.html XEP-0301] twice: first in 2.x.y and then in 3.0. I got as far as a working backend prototype that could send and receive real-time text stanzas.
+
+However, RTT is a large and difficult feature to implement robustly. The format of the data, when it is transmitted and received, and how the GUI responds to it are all fundamentally different than IMs or group chats. Libpurple's core infrastructure is divided between IMs and group chats, with an individual "stack" for each. It seems to me that the only way to properly implement RTT is to add a third stack for RTT.
+
+On one hand, this stack can be much more minimalist than that of IMs. For example, there is no concept of typing status (a feature which demands a lot of code) or HTML in RTT, and RTT demands far fewer GUI hooks. However, adding a full additional stack demands a lot of boilerplate and code duplication. Additionally, I find the XEP overengineered, which may partially explain why (to my knowledge) no major chat application supports it yet.
+
+I still hope that RTT gets added to Pidgin, but it may not make it for the 3.0 release. If you're interested in working on it, let me know and I'll be happy to help.