Warning: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in ..../includes/class_bbcode.php on line 2958
Developer wanted -- Adding optional real-time text to Miranda IM
Miranda IM

Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Developer wanted -- Adding optional real-time text to Miranda IM

  1. #1

    Developer wanted -- Adding optional real-time text to Miranda IM


    I'm Mark Rejhon, the author of the XMPP/Jabber Real Time Text extension (xmpp.org/extensions/xep-0301.html).

    Wikipedia: Real-time text
    Animation: What real-time text looks like

    I am researching open source clients (Miranda, Pidgin, Adium, etc) and determining which should be the first client that should gain this real-time text feature. I'd like all clients to support it; best practice is supporting it as an on/off feature through a supplemental menu item or button (like turning on/off audio and/or video).

    I wrote some sample source code, which is available at realjabber.googlecode.com (C#), most particularly in the RealTimeText.cs module.

    Anybody who would like to step up to the plate, and add real-time text to Miranda?
    Last edited by Mark Rejhon; 2 Sep 2011 at 6:06 PM. Reason: Rename title

  2. #2

  3. #3
    Join Date
    March 2005
    So, basically this is what ICQ was able to do ~14 years ago and a feature that most users hated so much that ICQ decided to nuke it?

    I'm not really excited and probably wouldn't ever want to use that, but maybe there are a few special cases where it makes sense.
    • TabSRMM Wiki - documentation for TabSRMM
    • Blog
    • contact (GMail / GTalk): silvercircle(at)gmail(dot)com

  4. #4
    Join Date
    March 2005
    United States
    It is an odd feature. Technically, you would have to update the srmm api to support this along with the Jabber protocol plugin itself. I guess its mostly trivial although I hate to add a that type of api to srmm as it seems like it would never be used by another protocol and would require srmm/tabsrmm/scriver all to be updated to be of any use. And I guess some type of toggle to srmm or to the usermenu would be in order to make it configurable per user.

  5. #5
    Forget the developers - what's more important is that you would need users to use it. It looks quite fancy, when you compare those images, but really... Who wants someone else so see exactly what you are typing? Every letter, every mistake etc? Not me and probably not many other people either. And if what Nightwish wrote is true (and probably it is, I don't have any reasons to doubt him) then you should already dump the project ;)

    But anyways... Good luck.

  6. #6
    Join Date
    April 2005
    Not to mention the overhead it'd create. The TCP packet header will be by an order of magnitude longer than the data sent within.

  7. #7
    Here are some important points:

    Real time text is OPTIONAL -- OFF by default

    (1) It is an optional feature that is OFF by default.
    Did you know AOL's Instant Messenger has this real-time text feature too?
    I bet you didn't -- the feature is OFF by default.

    (2) This feature is useful to deaf. (I am deaf)
    If 1%, 5%, 10% of people want this feature, it is worth adding

    (3) Bandwidth is not as big an issue as 10 years ago.
    In-band audio and file-transfers over XMPP uses more bandwidth.

    (4) ICQ's split screen chat feature was off by default too. The feature was removed because of many considerations, not because users hated it (even if complainers contributed). It was removed because it required peer-to-peer connections, and the Internet was starting to become more firewalled (routers were starting to be coming out, etc). Before around 1998, people at home didn't use routers. Direct peer-to-peer software such as Unix Talk and ICQ Split Chat, were all getting more buggy to keep working reliably. The XEP-0301 protocol solves these problems. Do you hear of people complaining about AOL's AIM real-time text feature? No -- they were careful to make it a very optional feature that is used only by people who are interested in using it.

    (5) Real-Time text is a feature that can be turned ON/OFF like video or audio can be turned ON/OFF :-)
    Real-Time Text is optional. Audio and video is OFF by default, too.

    People arguing against an optional feature that's OFF by default, does a great disservice to the disabled, and there are a great many people (even 10% of 1 million is still 100,000) still want Real-Time Text.
    People like me cannot use the telephone --
    real-time text is the next best thing.
    That is why I invented XEP-0301.

    Not everyone like video.
    Not everyone like audio.
    Not everyone like real-time text.
    All 3 are OFF by default, anyway. What's the harm? :-)

    Quote Originally Posted by rainwater View Post
    It is an odd feature. Technically, you would have to update the srmm api to support this along with the Jabber protocol plugin itself. I guess its mostly trivial although I hate to add a that type of api to srmm as it seems like it would never be used by another protocol and would require srmm/tabsrmm/scriver all to be updated to be of any use. And I guess some type of toggle to srmm or to the usermenu would be in order to make it configurable per user.
    If America Online publishes their Real-Time Text protocol for AOL Real-Time IM.... (you may be surprised to know AIM already supports Real-Time Text in AIM 6.8 and later. The feature is OFF by default) .... Then there could be a common conduit for real-time text on other chat networks.


    I am throwing in a $200 bounty (by PayPal) for this feature to be added to Miranda IM, compliant to XEP-0301. Google my name "Mark Rejhon", and visit my websites at www.marky.com and www.realjabber.org ... If anyone takes up this bounty offer, please email me at mark[at]realjabber.org

    It is an important feature for the disabled. Remember, it's OFF and unobtrusive (just like AOL AIM's real-time text feature that was introduced 3 years ago). You never hear about people complaining about AOL AIM's real time text feature because they were careful to make it OFF by default and unobtrusive. My XEP-0301 is an open standard, unlike AOL AIM's proprietary real-time text feature.
    Last edited by Mark Rejhon; 12 Jan 2012 at 10:37 PM.

  8. #8
    Join Date
    April 2005
    One bad decision of one company not going to be an argument.
    I'm "deaf" too. I don't understand English from listening. Although 90% of converstations in past four years have been in English. I don't see how it could be useful for me. I'd rather save my conversation partner time NOT staring at me writing text, and let him/her do own biddings in meantime.
    Bandwidth is always a concern.

  9. #9
    I'm the same way a lot of the time -- I appreciate the asynchronous conversations. I read many times faster than even fast typists, so I can do other things while waiting for people to type. That's why email and texting is very efficient.

    Again, RTT is OFF by default...
    ...and the discovery feature was added to the spec to allow it to force-disabled on both ends, if need be for those who do truly hate RTT (to prevent incoming negotiation requests for enabling RTT).

    But sometimes RTT becomes useful for some people (maybe not you, but it is for some others)
    -- There are other times where I am in 'conversational' mode.
    -- TDD/TTY's can be substituted with Real Time Text for many purposes. Example, connections to Relay Service. For example, IP-Relay on cellphones. (see http://www.ip-relay.com/im/ ...) This is very slow, because you have to hit Enter before they see the message. RTT allows message to behave like TDD/TTY instead.
    -- TDD/TTY's are ancient 45 baud devices, which is even more inefficient than RTT. Maybe YOU do not use TTY's, but other deaf people do. Give other deaf people a choice. Some do sign language, some don't. Some use TTY's, some don't. Some use relay, some don't. Some use RTT, some don't.
    -- Yes, bandwidth is alway a concern. That's why RTT is off by default.
    But remember, RTT is good for telephone conversations by deaf. It's not for asynchronous conversation. I actually only need RTT about 25% of the time.
    -- Other people definitely want RTT. One of the people who helped me with XEP-0301, had a test group that more than half liked RTT -- they'd use it at least occasionally, especially when it is needed conversationally. (i.e. use when a telephone substitute is needed, like a TTY/TDD substitute)
    -- Relating to one of my careers, there is talk behind the scenes within the industry (NG911 - sequel to E911 in the next decade or so) for the deaf that includes a form of real time text (like TDD/TTY sent over the Internet), i.e. for the deaf to be able to text 911 using RTT. There are many candidates, including RFC4103, XMPP, etc. (consider that Apple and Google are transitioning from SMS to XMPP for text messaging, so naturally, XEP-0301 may fit here as a long term goal.)

    When I mentioned AOL AIM, that's not a company's decision but a collaboration by a deaf university, Gallaudet near Washington DC -- http://tap.gallaudet.edu/text/aol/ .... Anyway, there we go. There are several companies adding RTT to experimental software programs, so it's actually expanding again.

    BTW, I've downloaded Miranda source code, and see RTT can be hooked into via CJabberProto::OnProcessMessage of jabber_thread.cpp (~line 1150ish) for monitoring the <rtt/> element specified by XEP-0301 and passing it along to jabber_rtt.cpp for processing. The trick is to do it unobtrusively with self-contained changes (as much of it in jabber_rtt.cpp module as possible, and keep it from polluting from the rest of the code) following the existing coding guidelines/standard of Miranda, obviously, and keep the feature off by default. The srmm api would certainly be the most 'disruptive' area, but might be simplified to some form of an 'update existing message' API call, even as crude as replace-whole-message (i.e. perhaps keeping jabber_rtt.cpp doing its own incremental updates internally, keeping that mess out of srmm api). ...

    In addition, it may be an opportunity to optimize the redraw code a little bit to higher performance / flicker-free, since that's important message is being refreshed during rtt typing. I've noticed that in Miranda, the redraw code has certain inefficiencies even without RTT; I see some flickering of the statusbar when Miranda is run on slower computers, when a key is pressed down (Miranda redraws the whole statusbar every keypress in the local input buffer!). So redraw optimizations will benefit the performance of non-RTT conversations. The redraw flicker doesn't show on fast computers, but shows up on slower (hold down a key in the local send buffer and watch carefully for flicker in the status bar in the current version of Miranda.) Anyway, I might be wrong with the whole general approach (and probably need to study more), but this seems to be my first impression of the easiest way to add XEP-0301 in a minimally disruptive way, and also benefit the graphics performance of non--RTT conversations (especially when people try to use Miranda on slower netbooks), to make the patch more attractive...

    I have many other XMPP clients I'm working on, including niche market stuff (mainly where it replaces TDD/TTY text telephones for the deaf)... My paid projects make me too busy to program code for Miranda (so I've already benefited from XEP-0301), but I'm happy to donate some of the XEP-0301 related code to GPL if required if it helps. I have Java source code to donate to open source (GPL compatible) or at least to research from, even though Miranda is in C/C++. If a developer steps up (Current bounty of $200, out of my personal pocket cash), feel free to contact me.
    Last edited by Mark Rejhon; 16 Jan 2012 at 9:21 AM.

  10. #10
    Me and a few others (at the Real Time Text Foundation, realtimetext.org -- yes, there's a Foundation) have been discussing various pros and cons. RTT, as Real Time Text.

    The requirement to support the deaf
    -- Demand for RTT has been increasing. Many proprietary RTT protocols are used by half a dozen relay services, and even a standard messenger AIM uses a proprietary RTT protocol
    -- XEP-0301 provides a standardized protocol

    The need to be minimally intrusive, when used in a mainstream chat client.
    -- Turned off by default, just like audio chat is off by default, and video chat is off by default
    -- There should be proper/polite initation mechanism (so you can decline RTT like for declining audio chat)
    -- Much like many don't like audio or video, RTT is "another" thing that can be kept turned off
    -- Experience has shown that the youth market has an interest in RTT from time to time, and would use it "at least some of the time"; this is a market beyond the deaf-accessibility market (as people like me cannot use the telephone)
    -- For people who hate watching typing mistakes, RTT can also be made to "buffer by the word" -- transmitting only completed words when the spacebar or Enter is hit;
    -- There are other ideas that comes up.

    I know that it can sometimes be hard to add to an existing UI.
    The need to add UI modifications with minimal impact, can include following ideas:
    -- RTT can show up inline in the existing UI (I know this can be hard to code)
    -- or RTT can show up in a separate small popup window, keeping UI changes away from main app (Video chats often have their separate popup windows too, this is an easier UI extension)
    -- or RTT can show up in a balloon popup when mouseover "Recipient is Typing..." notification
    -- or for API-based UI's a function call / API hook is made in the existing UI called "Replace Current Message". The message is replaced in a flicker-free way. The RTT module would be responsible for keeping track of the current message contents, and update the window whenever the message text has changed (whether a single keypress for full flow, or a few keypresses at a time on timer, etc)
    -- For outgoing RTT transmission, a hook needs to be made everytime the message-entry box changes.
    -- For an initial stage of a project, it is simple to just support only the insert/delete/backspace codes in the XEP-0301 protocol. (i.e. ignoring all the other codes in the XEP-0301 protocol)

Similar Threads

  1. Real idle time
    By SpinalBlood in forum Technical Support
    Replies: 5
    Last Post: 7 Feb 2010, 11:47 PM
  2. Feature - editing/adding time/messages in history
    By jon222 in forum Feature Requests
    Replies: 5
    Last Post: 15 Jul 2008, 3:36 PM
  3. Miranda needs a real update function
    By 3dgamer in forum Feature Requests
    Replies: 5
    Last Post: 12 Oct 2007, 3:14 PM
  4. Add an optional EX_STYLE
    By Yaron in forum Feature Requests
    Replies: 0
    Last Post: 3 Oct 2007, 10:53 AM
  5. Adding non-real ICQ contacts
    By needleboy in forum Technical Support
    Replies: 1
    Last Post: 19 Apr 2005, 11:40 AM


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts