Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
Communications Technology

Real-Time Text Over Jabber/XMPP/Google Talk 106

Posted by timothy from the no-room-for-oopses dept.
mdrejhon writes "Geeks who miss the UNIX 'talk' days, have a new modern savior: XMPP.org has published the new XEP-0301 Real-Time Text standard, which allows streaming text that is continuously transmitted as it is typed or otherwise composed. It allows conversational use of text, where people interactively converse with each other."
This discussion has been archived. No new comments can be posted.

Real-Time Text Over Jabber/XMPP/Google Talk More

Real-Time Text Over Jabber/XMPP/Google Talk

Comments Filter:

  • Not for the disorganised (Score:5, Funny)

    by Chris Down ( 2350174 ) on Thursday July 07, 2011 @04:38PM (#36687304)

    "http://www.redtube.c-"

    "sorry, wrong vt"

  • oh how i miss you.

    • Re: (Score:1)

      by Anonymous Coward

      After 2 years of russian spam, I finally logged out of my 6 digit account for good. As much as I used to love ICQ it just went down and down and downhill after they sold out until finally no one used it but fucking bots and idiots like me.

  • Missing the point of text. (Score:1)

    by Anonymous Coward

    I want to think about what I'm typing before I let the other person know about it.

    • This feature can be turned on/off.

      It is a feature that is very friendly to the deaf, as the spec even mentions deaf people in the introduction of the specification document.
      http://xmpp.org/extensions/xep-0301.html [xmpp.org]
      "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times

  • Now I can idle in real-time.

  • No (Score:5, Insightful)

    by Normal Dan ( 1053064 ) on Thursday July 07, 2011 @04:41PM (#36687336)
    I do remember the days of real-time text. I don't want it back. I make too many typos and other such mistakes. I'd rather not let others watch me type.
    • <>pI agree with you, . This is a terrivble idea!<>/p

    • Re: (Score:2)

      by antdude ( 79039 )

      It should be an option for a real-time or after hitting enter/send.

    • Understandable, but real-time text can be turned on/off.
      Some users like, it and some don't. AIM has an enable/disable feature for Real-Time IM.
      It can be an optional feature, like optional audio or video in their IM chats.
      I'm a deafie, and it's beneficial to use from time to time.

    • Re: (Score:3)

      by adolf ( 21054 )

      As a former WWIV [wikipedia.org] sysop who has since been twirling around on Teh Intarwebs for almost two decades, I miss split-screen chat.

      It's much more conversational.

    • I do remember the days of real-time text. I don't want it back. I make too many typos and other such mistakes. I'd rather not let others watch me type.

      OTOH, if you run ytalk [iagora.com], you can share a command-line session and use it as a teaching tool

    • As Jabber wraps each message in a bunch of XML and for federated systems sends it to the other system much like one would send an email via SMTP, this would obviously wrap each letter typed in a bunch of XML, and send each letter as an individual message.

      • Actually, the spec does a compromise to transmit only 1 packet per second, even if there's 10 key presses per second.
        It buffers the key presses for a full second, even including the original intervals between the key presses.
        Then it transmits XML for the whole sequence, all at once.

        This avoids overloading the network with too many messages per second, while keeping it sufficiently real-time, in a balanced compromise. (Yes, I know, it's "inefficient" XML, but XMPP.org encourages ease of programming over ban

        • Thanks for the info. I wonder how difficult something like google chat would be to integrate such a system. As it keeps all IM messages in its system. I'm guessing these wouldn't be captured?

          • It wouldn't be difficult for Google to add it to Google Talk (unobtrusively, turned off by default)...

            It works on Google Talk's network already via third party software. Thus, no XMPP server modifications needed.

            An example is RealJabber experimental demo chat software whose source code I posted at http://realjabber.googlecode.com/ [googlecode.com] ... I tested XEP-0301 real-time over google's XMPP severs (gmail.com / talk.L.google.com) ... Google was able to handle up to more than 10 XMPP messages per second very easily, b

          • Oh -- and Google does not capture all messages.
            There's lots of hidden XMPP message transmissions that goes on for other things, and Google does not log those.

            XEP-0301 is intentionally designed to be backwards compatible, so you can safely transmit real-time text to any XMPP chat software, and it just ignores the real-time text part. It just displays only the finished (completed) messages. Though section 5 of the XEP-0301 spec recommends that you detect whether the remote end supports the real-time text,

  • Oh, cool! (Score:5, Insightful)

    by LSD-OBS ( 183415 ) on Thursday July 07, 2011 @04:41PM (#36687342)

    Welcome to 2011, where 1981 is continuously re-invented

    • Re: (Score:1)

      by Anonymous Coward

      It wasn't new in 1981 either. You just thought it was at the time. Every generation thinks that their ideas are original, that the next generation rips them off and they lack the knack for innovation. Ask your parents, they'll tell you the same thing about your generation.

    • I remember a client called LOLChat that did this.

    • Re: (Score:3)

      by phoebe ( 196531 )
      Wrapped in a large XML turd and not even following XML philosophy at that, randomly introducing one character tags. How is this protocol really helping anything?

      <t p='#'>text</t> Insert specified text at position p in message.
      <e p='#' n='#'/> Deletes n characters of text to the left of position p in message.
      <d p='#' n='#'/> Deletes n characters of text to the right of position p in message.

      • Re: (Score:2)

        by LSD-OBS ( 183415 )

        It's fucking disgusting, if you ask me.

        We need to stop shoehorning the kitchen sink into HTML. For example, to do Real-Time Communications on the Web, we now have WebRTC.

      • Do you really think that matters? The transmitted XML is smaller than the IPv6 header, the TCP header, the ethernet frame headers, etc.

        But if you really care, you can use compression schemes to reduce it. The gzip that's currently supported won't help for small messages, but it might help for this:

        http://xmpp.org/extensions/inbox/compress-exi.html [xmpp.org]

      • Re: (Score:2)

        by Roogna ( 9643 )

        Indeed. Nothing like "modern" technology to take something that was done regularly in the past, and reinvent it by taking up 100x more bandwidth and storage.

      • There's an excellent reason for the XML (in)elegance.
        - We first tried a compact binary protocol, base64 encodings, and other alternate encodings.
        - But, XMPP prefers XML-based protocols.
        - We wanted ease of software development, so ease outweighed a lot of factors.
        - Deaf-friendly: Something that can be added to existing traditional chat interfaces in existing chat software (much like AOL's proprietary Real-Time IM, but as an open standard). It can be turned on/off
        - We chose delibrately short XML tags to reduc

        • <w> allows transmitting of key press intervals, so that one packet can playback 10 keypresses naturally. XEP-0301 is the world's first real time text standard that packetizes the delays between the key presses, so you can transmit only a few packets per second. And yet keep the typing smooth.

          I do need to correct that last sentence.
          As shown in the animation, "you can transmit a multiple keypresses in only one packet per second. And yet keep the typing smooth."

          • Re: (Score:2)

            by Rhaban ( 987410 )

            do you really need to send a delay?
            did you try dividing a second by the number of characters in the packet to automate smoothing on the receiving end? If you did, what did not work? didn't feel natural?

            • Yep, that worked, and it works well.
              In fact, XEP-0301 mentions that an alternate smoothing method can be used as an alternative in the last bullet of Section 6.2.3.

              However, because this standard is designed to benefit deaf people like me:
              Some of us deafies are sensitive to 'emotion' in typing. People type differently when calm (smooth, typo free) or panicked (fast, lots of typos), or tired (slow, more typos). When we talk to the same person frequently, we can pick up the emotion partially from the typing,

    • I wonder if Google Wave's code or ideas set this off - eg real time stuff over XMPP.

      • That was one of the first features of Wave anyone I knew wanted to turn off.

        It's like interrupting someone as their thoughts are coming through because you think you can guess the end of the sentence. Half-formed thoughts just fail to work in that context.

    • 80's try the 1920's. It was called Telex.

  • they finally figured out talk and ytalk. Good for them.

  • This reminds me of a beautiful plugin for one of the chat clients, I can't remember which one now, that exploited the 'realtime typing notification' option that one of the IM systems offered.

    By default, the client would only show typing notifications if you were already chatting with someone. This plugin warned you of typing notifications from people just initiating a conversation, which usually gave you time to quickly reply to them before they had a chance to say something to you. Totally freaked out t
    • I believe GaIM/Pidgin did this. It would pop up with the message "You feel a disturbance in the force...". And I agree, great for creeping people out :)

    • Re: (Score:3)

      by TypoNAM ( 695420 )

      You're thinking of the Psychic Mode plugin that comes with Pidgin [pidgin.im] of which is also used by the Bot Sentry plugin [sourceforge.net] to filter out spam messages. I remember the first time I got Bot Sentry working and noticed that it pretty much eliminated the spam problem coming from both ICQ and MSN networks, but the first time I saw "You feel a disturbance in the force" a week later kind of freaked me out as I didn't realize that was Psychic Mode's default behavior.

    • Re: (Score:2, Funny)

      by ensignyu ( 417022 )

      A long time ago I wrote a GAIM (Pidgin) plugin as a prank based on the observation that people usually try to avoid responding at the same time by watching the typing icon; if one person is typing, the other person stops typing to give the first person a chance to finish.

      The plugin, instead of reporting my typing status, would *mirror* the other person's typing status. So as soon as they started typing, it would indicate that *I* was typing as well. Most of my friends didn't realize what was going on; they

  • I've been in many jobs in the last ~15 years where a chat infrastructure is a standard tool of the IT group.

    I've also seen managers, who traditionally kept out of the admin channels, start to invade them, in the name of "keeping a pulse of the group's activities and issues..."

    No sir, I don't want or need my boss seeing what I type and erase in the chat client before I type a calmer chat and hit enter.

    Do Not Want.

    • Re: (Score:1)

      by atisss ( 1661313 )
      Boss is one thing, but imagine accidental paste from wrong clipboard :p

    • The spec is actually more targetted towards deaf-friendliness. The spec mentions:
      "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see Re

  • On talk(1) they can see you type(o) (Score:5, Funny)

    by bill_mcgonigle ( 4333 ) * on Thursday July 07, 2011 @05:06PM (#36687712) Homepage Journal

    I used talk recently when stuck in an odd situation. The guy on the other end and I usually use IM.

    His comment to me, "christ, Bill, you type like shit."

    • Re: (Score:2)

      by Xtifr ( 1323 )

      And that's why those of us who can type miss it! We miss making fun of our friends who cant'! :)

  • Transmitting a TCP packet every time a character is typed seems kind of inefficient unless there is a big gain here.

    • Re:What's the advantage? (Score:5, Informative)

      by White Flame ( 1074973 ) on Thursday July 07, 2011 @05:21PM (#36687908)

      Not just a TCP packet, but a mass of XML!

      • Re: (Score:2)

        by TFoo ( 678732 )
        Seriously. It is difficult to express in words just how inefficient XMPP is as a protocol -- and this will be even worse! Sure, it's not a big deal on the client side, but real-world XMPP servers spend a substantial amount of time just parsing XML stanzas...and this would be a worst-case for them. Wow.
        • If XMPP and its XML gobblydegook aren't the "wave" of the future, then what protocol should/must win out from a technical perspective? Of course, I keep in mind that the best doesn't necessarily always win out, but for kicks and giggles...

          • Re: (Score:2)

            by adolf ( 21054 )

            If XMPP and its XML gobblydegook aren't the "wave" of the future, then what protocol should/must win out from a technical perspective? Of course, I keep in mind that the best doesn't necessarily always win out, but for kicks and giggles...

            How about Skype?

            *ducks*

        • You are optimizing (or suggesting someone else do) prematurely. To quote

          "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil"

          At least, I haven't heard of any networks being swamped with XMPP traffic, or even marginally affected by it. If you want to optimize something, have a look at P2P, streaming or spam.

      • Re: (Score:2)

        by msh104 ( 620136 )

        From what i understood this is not what they do.
        They check what key strokes have been entered in the past second and at what interval.
        They then transmit all this information to the other side where this is being shown.
        So while typing, one XML request / second is being send.

        Still a lot of xml requests, but a nice compromise if you want natural typing in semi-realtime ( one second delay ).

        • Good answer.

          Some interesting notes to add, for this technology:
          -- It's also allowed to use a different transmission interval (i.e. 300ms) to reduce the lag, especially if you're using your own XMPP network where you can control the servers, etc. If using your own LAN XMPP server, you could even turn off transmission buffering and transmit all changes/keypresses immediately, but that's not a good idea for the public XMPP network, since that means 30 XMPP messages a second for a key being held down (auto-r

    • I actually thought of this.
      XMPP real-time text is the world's first real time text protocol that encodes key press delays:
      http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]

      So even at 10 keypresses per second, even over a satellite connection (or other high-latency bursty connection), it only needs to transmit 1 packet per second, and the typing comes out naturally.

      XEP-0301 (the protocol) is a packetization of typing including typing delays, much like VoIP packetizes short snippets of audio.
      Explained i

  • At last... (Score:5, Funny)

    by coreyh ( 30451 ) on Thursday July 07, 2011 @05:21PM (#36687904) Homepage

    ...all of my ^H^H^H jokes will be funny again.

  • files (Score:3)

    by hey ( 83763 ) on Thursday July 07, 2011 @05:22PM (#36687922) Journal

    Last I tried sending a file via XMPP it still (after what 10 years) failed.
    That would be a nice thing to work out first.

    • Comment removed based on user account deletion
    • I looked into this recently. It seems there are plenty of methods in XMPP for sending files in our modern mess of NATs. However, IM clients haven't necessarily kept up with the XMPP standards. The libpurple based clients (Pidgin, Adium, etc.) in particular seem to be stuck with the XMPP of several years ago. I've had better luck sending files with Psi, but that client is kind of clunky. Anyway, I suspect that file transfer is considered to be a solved problem from the point of view of the XMPP standard

      • Sending files in-band can fail/get stuck as GP said; also it is often capped by administrators. In my peer-to-peer filesharing application, dubbed Jake [sf.net], I use XMPP to negotiate a ICE/STUN peer-to-peer connection. If that fails, there is always the in-band method to fall back to. (The backend seems to work decently, the GUI and testing needs work though)

        The jingle protocol is supposed to be for XMPP what ICE/SIP is for VoIP, but there are only few implementations.

    • Sorry about that. I was sending an Internet and the tubes must've been filled.

  • Am I doing it right? (Score:3)

    by GameMaster ( 148118 ) on Thursday July 07, 2011 @05:38PM (#36688090)

    I'm going to copy-paste all my comments to reproduce the feel of that old-time instant messenger experience.

  • I thought that when Google announced Wave they said it used XMPP for the communications. I assume this is just a formalization of what was created back then?

  • Why? (Score:1)

    by Meeni ( 1815694 )
    Why?

    • It's a good assistive technology feature for the deaf too. In fact, the Introduction also mentions its use by the deaf, too:
      http://xmpp.org/extensions/xep-0301.html [xmpp.org]
      "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the

    • Re: (Score:2)

      by ErikZ ( 55491 ) *

      I would prefer this than regular messaging. When you see the words being typed, it means the other person is there, right now.

      No more lags as the person you're typing to gets bored and starts checking out web pages or IM other people. Keeps the conversation flowing and total time MUCH shorter.

  • I'm the author of this standard. I'm also a deafie (Score:5, Informative)

    by mdrejhon ( 203654 ) * on Thursday July 07, 2011 @08:03PM (#36689314) Homepage

    Hello --

    Some general comments that addresses common comments:

    (1) This is an optional feature that can be turned on/off.
    You only use it when you want it, so you don't have to show off your typos to everyone, if you don't want to.
    Just like audio can be turned on/off and video can be turned on/off.

    (2) It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
    http://xmpp.org/extensions/xep-0301.html [xmpp.org]
    "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by the deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

    (3) It's not inefficient in message rate. It is only one packet per second, no matter how fast you type, even 30 keypresses per second (holding a key down). As far as I know, this is the world's first real-time text protocol that preserves key-press delays for chats. This means typing still looks smooth, even at low packet rates (1 packet per second), even if you are typing at 10 or 30 keypresses per second. Even over a satellite connection, or even over a dial-up connection (while an FTP is going on in the background), or over a mobile phone connection that has intermittent reception and variable ping latency.

    (4) There is an animation of the key press intervals (delay coding) at:
    http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]

    (5) Some existing software already have this feature, that you may not notice, because it's off by default. For example, AOL Instant Messenger's "Real-Time IM" feature is a proprietary version of real time text, while XEP-0301 is an open standard that anyone can use for Jabber-based networks.

  • does no one remember?

    • Re: (Score:2)

      by hitmark ( 640295 )

      I do, had some fun with it (and the typewriter sounds) back when i first got online. I think i still have the ICQ number registered, but unsure if i recall the password any longer.

    • Re: (Score:2)

      by Dan541 ( 1032000 )

      I remember using that back in 1998. That's when I first got ICQ, it was revolutionary at the time.

  • You saw every keystroke that other people were typing in real time. I think there are real advantages, because you anticipate what someone is abou to type and interrupt them in realtime. I think that can save time in some conversations. However, the typos, and the backspaces did become tedious.

  • I'm texting in real-time, oh wait, I have a phone....

    I'm going to make a voice phone call. Much easier and faster.

    • It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf:
      http://xmpp.org/extensions/xep-0301.html [xmpp.org] [xmpp.org]
      "Real-time text is text that is sent as it is created. The recipient can watch the sender type "as written words are typed" – similar to a telephone conversation where one listens to a conversation "as words are spoken". It provides a sense of contact in conversation, eliminates waiting times found in messaging, and is also favored by

Slashdot Top Deals

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Close