×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

106 comments

Not for the disorganised (5, Funny)

Chris Down (2350174) | more than 2 years ago | (#36687304)

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

"sorry, wrong vt"

Re:Not for the disorganised (1)

Fast Thick Pants (1081517) | more than 2 years ago | (#36687376)

You're actually typing "http://www."? I don't think redtube's gonna work too well from Mosaic.

Re:Not for the disorganised (1)

Chris Down (2350174) | more than 2 years ago | (#36687426)

I don't know. I just like to open pages on Redtube in Mosaic and let my imagination do the work.

Re:Not for the disorganised (0)

Anonymous Coward | more than 2 years ago | (#36687596)

When I first read your comment, I was thinking of a Mosaic http://en.wikipedia.org/wiki/Mosaic

Opening redtube as a mosaic instead of in mosaic gives a little bit different image.

Re:Not for the disorganised (1)

vegiVamp (518171) | more than 2 years ago | (#36693438)

typing in an instant (sorry, realtime) messenger - you need the http prefix for it to transform it magically into a link.

ICQ (1)

spire3661 (1038968) | more than 2 years ago | (#36687322)

oh how i miss you.

Re:ICQ (1)

Anonymous Coward | more than 2 years ago | (#36687582)

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. (1)

Anonymous Coward | more than 2 years ago | (#36687324)

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

Can be turned on/off. Also deaf-friendly, too. (2)

mdrejhon (203654) | more than 2 years ago | (#36689206)

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 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]."

No (5, Insightful)

Normal Dan (1053064) | more than 2 years ago | (#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.

Real-time text can be turned on/off. (2)

mdrejhon (203654) | more than 2 years ago | (#36689082)

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:No (2)

adolf (21054) | more than 2 years ago | (#36690848)

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.

Re:No (1)

VolciMaster (821873) | more than 2 years ago | (#36693052)

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

Re:No (1)

MindStalker (22827) | more than 2 years ago | (#36693362)

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.

Keys are buffered to keep transmissions reasonable (1)

mdrejhon (203654) | more than 2 years ago | (#36694790)

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 bandwidth efficiency. I'm fine with that. Besides, it doesn't really use much total bandwidth, anyway, especially since XMPP now permits base64 transmissions of avatar images and file transfers, etc -- all of which use more bandwidth than real time text. And the capped message rate is very reasonable.)

As this spec is partly designed for use by deaf people (including me; the specification's introduction specifically mentions this assistive use, too.), it is very desirable to see the original delays between the key presses. There is an animation of the key press interval encoding:
http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]
As you notice in the animated GIF in the above link, there is a slight 'emotion' in the keypresses (calm typing versus panicked/emphatic typing) that deaf people like to pick up on, when supplemented with other contextual cues (text content, emoticons, etc).

Note -- For everyone else, the real-time feature can be turned on/off like audio/video is already an on/off feature in chats.

Re:Keys are buffered to keep transmissions reasona (1)

MindStalker (22827) | more than 2 years ago | (#36696164)

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?

Re:Keys are buffered to keep transmissions reasona (1)

mdrejhon (203654) | more than 2 years ago | (#36696610)

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, but XEP-0301 limits it to a recommended setting of just 1 XMPP message per second maximum, to be gentle on the network. (In fact, that's probably comparable to text-happy kids who say "Hi" "wassup" "u?" and type those messages once a second before transmitting them -- ha ha -- annoying to our group, but the XMPP network clearly can handle a protocol that requires a once-a-second message rate.)

I am working with several parties that are creating clients for Android as well as in AJAX/JavaScript (Linux/Android/iPad compatible). To prevent annoying users, Google could keep it turned off by default, but just an on/off menu item or button. Turning on/off real-time text like turning on/off audio or video. (It shouldn't be annoying as Google Wave that way, yet provide an important service for deaf people like me, and for people who *do* feel like turning on the feature -- even 1% or 10% is still a lot of people).

In fact, some existing chat software sometimes have real time text already (AOL AIM's "Real Time IM" -- a feature that is turned off by default and is a feature usually not discovered by most non-deaf people. Unfortunately, it is proprietary, unlike the open XEP-0301 protocol that anyone can use over Jabber/XMPP.)

P.S. You can't believe how some of us deafies are stuck with older technologies. For example, our text telephones (TDD / TTY) run at 45 baud! (Yes. 45. that's slower than 300 baud -- don't believe me? -- see http://en.wikipedia.org/wiki/TDD/TTY [wikipedia.org] ..)

Re:Keys are buffered to keep transmissions reasona (1)

mdrejhon (203654) | more than 2 years ago | (#36696750)

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, and to avoid transmitting real-time text, in order to save network bandwidth.

So existing software without real-time would work fine, even when connected to a real-time capable client that's intentionally transmitting real-time messages. (they're ignored since it's an additional XML element that's ignored, and only the finished full line of messages are displayed)

Oh, cool! (5, Insightful)

LSD-OBS (183415) | more than 2 years ago | (#36687342)

Welcome to 2011, where 1981 is continuously re-invented

Re:Oh, cool! (0)

Anonymous Coward | more than 2 years ago | (#36687408)

Also 1984.

Re:Oh, cool! (1)

Anonymous Coward | more than 2 years ago | (#36687484)

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.

Re:Oh, cool! (0)

Anonymous Coward | more than 2 years ago | (#36688428)

Morse code, semaphore, and smoke signals are also real-time. Yes, it takes time to decode, but so does imspeek

Re:Oh, cool! (2)

phoebe (196531) | more than 2 years ago | (#36687630)

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.
  <c p='#'/>            Move cursor to position p in message.
  <w n='#'/>            Execute a pause of n hundredths of a second.
  <g/>                  Executes a flash/beep/buzz.

Re:Oh, cool! (1)

LSD-OBS (183415) | more than 2 years ago | (#36687698)

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.

Re:Oh, cool! (1)

icebraining (1313345) | more than 2 years ago | (#36688806)

HTML has nothing to do with XMPP, and only barely with the Web (you can use HTTP bindings, but AFAIK it's not commonly used).

Re:Oh, cool! (3, Informative)

mdrejhon (203654) | more than 2 years ago | (#36689272)

I know. :-)
One thing though, that isn't HTML, it's XML over XMPP. We used a binary code at first for XEP-0301, until I realized XMPP encouraged XML. Our task group chose one-letter XML elements, to save some bandwidth. Key press interval elements ended up being the best way to transmit real-time text, at only 1 packet per second (protecting the network), while fully preserving key-press delays, so that typing comes out naturally, thanks to the delay elements:
http://xmpp.org/extensions/xep-0301.html#key_press_intervals [xmpp.org]

See examples 7.1 through 7.9:
http://www.xmpp.org/extensions/xep-0301.html [xmpp.org]

As well as the animation of smooth typing (non-bursting text) even at just 1 packet per second:
http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]

Re:Oh, cool! (1)

Roogna (9643) | more than 2 years ago | (#36687842)

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.

Re:Oh, cool! (0)

Anonymous Coward | more than 2 years ago | (#36688444)

Wow, so someone reinvented the Wave protocol, poorly?

And what on earth would you use a "beep" command for?

Re:Oh, cool! (1)

Ash-Fox (726320) | more than 2 years ago | (#36688600)

And what on earth would you use a "beep" command for?

See Yahoo Messenger's buzz.

BlackBerry Ping / MSN Nudge / XMPP XEP-0224 (3, Insightful)

mdrejhon (203654) | more than 2 years ago | (#36690854)

And what on earth would you use a "beep" command for?

Darn near everybody else has it:

Yahoo Buzz
BlackBerry Ping
Windows Live Nudge
XMPP.org's XEP-0224 "Attention" (for Jabber / XMPP / Google Talk / etc)

This is a protocol optimized for assistive use for the deaf, too; and it can be turned on/off. (i.e. real time text is optional) This really, is an unobtrusive add-on that can be off by default (much like AIM's existing real time text feature is off by default)

The XML ended up being elegant, because... (2)

mdrejhon (203654) | more than 2 years ago | (#36691002)

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 reduce bandwidth. Yes, that does not follow XML philosophy in naming, but it is a bandwidth compromise.
- We delibrately avoided using tag names of existing HTML tags, even though this is a different XML namespace. We avoided <b> and <i> anyway.

First, see the animated GIF of this real-time text protocol, to see some of the reasons why this XML was chosen:
http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]

Now read section 7.1 through 7.9 of the XEP-0301 specification:
http://xmpp.org/extensions/xep-0301.html#action_elements [xmpp.org]

As you can watch in the animation,
<t> is insert text, to support transmission of key presses, text block inserts, and text being pasted.
<e> is backspace.
<d> is delete key (forward delete), or cutting / deleting blocks of text
<c> is cursor positioning (optional)
<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.
<g> is for backwards compatibility with similiar features like Yahoo Buzz, MSN Nudge, BlackBerry Ping, Jabber XEP-0224 Attention, etc. It is very deaf-friendly and this is optional and can be turned off, but some like this feature.

More info about these action elements:
http://xmpp.org/extensions/xep-0301.html#action_elements [xmpp.org]
Only the first 3 XML elements are required (insert, backspace, and delete)

So as you can observe, there is excellent rationale for the "turd" we had to use. It is for instant messaging conversations, not for things like Google Wave, and is rather instead an optional add-on to existing instant messaging that can be turned on/off.
http://www.marky.com/realjabber/real_time_text_demo.html [marky.com]

Re:The XML ended up being elegant, because... (2)

mdrejhon (203654) | more than 2 years ago | (#36691018)

<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:The XML ended up being elegant, because... (1)

Rhaban (987410) | more than 2 years ago | (#36691986)

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?

Response to time-based smoothing alternatives. (1)

mdrejhon (203654) | more than 2 years ago | (#36694244)

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, especially when supplemented with additional context (typed words, emoticons, etc). The spec encourages the use of high-precision transmission of delays in typing (Section 6.1.2), because that is more interesting than packet bursting (Section 6.1.1).

Time-based smoothing has the advantage of masking out typos especially if I do word transmission (giving the sender the opportunity to fix typos first). However, many deafies prefer seeing the original typing at high precision, for "maximum fidelity" of text-based communications.

The spec is being continually updated, to cover additional use cases, and this may be covered/clarified in a future update (since the spec is still in its Experimental stage, there is plenty of time to improve the spec; as XMPP.org gives every specification a mandatory minimum 12-month experimential period, before being upgraded to Draft status.)

Re:Oh, cool! (1)

styrotech (136124) | more than 2 years ago | (#36687890)

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

Re:Oh, cool! (1)

dakameleon (1126377) | more than 2 years ago | (#36689220)

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.

This reminds me... (1)

fuzzyfuzzyfungus (1223518) | more than 2 years ago | (#36687550)

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 those who didn't realize that their client was providing realtime status information...

Re:This reminds me... (1)

ryantmer (1748734) | more than 2 years ago | (#36687766)

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:This reminds me... (0)

Anonymous Coward | more than 2 years ago | (#36687872)

I turned that feature off. I don't tend to send things til I get a complete thought down and I try correct punctuation and grammatical mistakes. Would really dislike this realtime thing. I also hate google's thing of popping up search results when you only have like half a word in the box, and how even after typing in 3 words and waiting, hitting enter brings up different search results. What?

Re:This reminds me... (2)

TypoNAM (695420) | more than 2 years ago | (#36688022)

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:This reminds me... (1, Funny)

ensignyu (417022) | more than 2 years ago | (#36688618)

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 would start typing and then stop typing as soon as they saw me typing, at which point it would look like I stopped typing as well; rinse and repeat. Eventually they would just ignore my typing status (which I normally have turned off, anyway).

Cool (0)

Anonymous Coward | more than 2 years ago | (#36687600)

Will this be integrated into the upcoming Hollywood OS?

Not in the Enterprise anyway (1)

humphrm (18130) | more than 2 years ago | (#36687694)

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:Not in the Enterprise anyway (1)

atisss (1661313) | more than 2 years ago | (#36693318)

Boss is one thing, but imagine accidental paste from wrong clipboard :p

The feature can be turned on/off. (1)

mdrejhon (203654) | more than 2 years ago | (#36694362)

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 RealJabber.org [1].

That said, it's useful in the enterprise in certain contexts like an assistive-friendly workplace that does not involve boss chats, and also between two different engineers who intentionally turn on the feature (which is an on/off feature, like audio can be turned on/off and video can be turned on/off). In your use case, you definitely want to turn this feature off.

On talk(1) they can see you type(o) (4, Funny)

bill_mcgonigle (4333) | more than 2 years ago | (#36687712)

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:On talk(1) they can see you type(o) (1)

Xtifr (1323) | more than 2 years ago | (#36692334)

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

What's the advantage? (1)

sl4shd0rk (755837) | more than 2 years ago | (#36687760)

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? (4, Informative)

White Flame (1074973) | more than 2 years ago | (#36687908)

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

Re:What's the advantage? (1)

TFoo (678732) | more than 2 years ago | (#36688490)

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.

Re:What's the advantage? (1)

SpeedStreet (924467) | more than 2 years ago | (#36689136)

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:What's the advantage? (1)

adolf (21054) | more than 2 years ago | (#36690900)

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*

Re:What's the advantage? (1)

EsbenMoseHansen (731150) | more than 2 years ago | (#36692564)

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:What's the advantage? (1)

msh104 (620136) | more than 2 years ago | (#36692126)

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. (1)

mdrejhon (203654) | more than 2 years ago | (#36694568)

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-repeat)
-- Generally, instead of capturing keypresses, an even better method is to monitor for text changes instead.
This is because of the need to capture copy/pastes, automatic text replacements (auto spell checkers), voice recognition systems, special keyboards, that might not output one keypress at a time. Everytime the text in the sender's message changes, scan for the change (which is done in EncodeRawRTT( ) line 315 in RealTimeText.cs in realjabber.googlecoe.com ...) and generate the action elements that way. That way you capture all possible changes to the text, as generally recommended in Implementor's Notes in section 6.2.1 of the specification. Although keypress events are OK, if you can strictly control all other possible changes to text (i.e. alternative text entry methods, copy/pastes, etc)

Re:What's the advantage? (0)

Anonymous Coward | more than 2 years ago | (#36689010)

A separate packet per character would be inefficient, yes - that's probably why the recommended interval is once per second, not every character, and the intervals between characters are transmitted to give the appearance of natural typing.

It's only 1 packet per second, even at 120 WPM (2)

mdrejhon (203654) | more than 2 years ago | (#36689126)

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 in first section in section 6:
http://xmpp.org/extensions/xep-0301.html#implementation_notes [xmpp.org]

Re:What's the advantage? (0)

Anonymous Coward | more than 2 years ago | (#36689916)

How many TCP packets are sent/recv when one watches pr0n from those tubes? Ah, of course, theres a big gain in

I never quite figured out the allure of that... (0)

Anonymous Coward | more than 2 years ago | (#36687882)

I mean, I really don't think anyone wants to watch me type a word, delete back to the beginning because I misspelled it, retype it, the continue on to the end and then watch me go back to use the spellchecker to finally get it right (As happened 4 times writing this). When I watched that on Google Wave, all I did was yell at the screen "Okay - I know what you are typing. Just finish already!"

files (2)

hey (83763) | more than 2 years ago | (#36687922)

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.

Re:files (1)

Ash-Fox (726320) | more than 2 years ago | (#36688566)

Last I tried sending a file via XMPP it still (after what 10 years) failed.

I received a file today over XMPP just fine?

Re:files (0)

Anonymous Coward | more than 2 years ago | (#36688816)

was it a 10 year old file by chance?

Re:files (1)

tachyonflow (539926) | more than 2 years ago | (#36690172)

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 itself.

Re:files (1)

buchner.johannes (1139593) | more than 2 years ago | (#36690790)

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.

Re:files (0)

Anonymous Coward | more than 2 years ago | (#36690714)

If it took ten years to transmit, perhaps you should look into upgrading your pipe and test driving modern compression.

Re:files (0)

Anonymous Coward | more than 2 years ago | (#36690770)

Yes, sending files in-band can fail and 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)

Am I doing it right? (2)

GameMaster (148118) | more than 2 years ago | (#36688090)

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

IRC (0)

Anonymous Coward | more than 2 years ago | (#36688340)

> which allows streaming text that is continuously transmitted as it is typed or otherwise composed.
Wasn't it done already with a display mode in mIRC in user to user communication?

cap: antique
Yes, welcome to yesterday.

Wave extension coming to life (1)

tecker (793737) | more than 2 years ago | (#36688396)

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?

Re:Wave extension coming to life (1)

Ash-Fox (726320) | more than 2 years ago | (#36688552)

I thought that when Google announced Wave they said it used XMPP for the communications.

XMPP was used for federation in Google Wave, what is being done is not related to any sort of formalization of what was created back then.

Wave? (0)

Anonymous Coward | more than 2 years ago | (#36688630)

Oh, you mean the most hated feature of Google Wave? Yeah, I'm ok without it.

Re:Wave? (1)

mcvos (645701) | more than 2 years ago | (#36691922)

Was this the most hated feature? There are plenty of cases where this is very appropriate. The problem with Wave was that your conversations quickly turned into a jumbled mess where you had no idea what the most recent contributions are.

But yeah, my first thought was: didn't Google Wave already do real time text over XMPP?

Why? (1)

Meeni (1815694) | more than 2 years ago | (#36688936)

Why?

Re:Why? (2)

mdrejhon (203654) | more than 2 years ago | (#36689182)

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 deaf who prefer text conversation. For a visual animation of real-time text, see RealJabber.org [1]."

- It's an optional feature, that can be turned on/off as usage warrants
- Just like audio can be turned on/off, and video can be turned on/off, real-time text can be turned on/off
- It utilizes traditional instant messaging UI, too.

It's also found in AOL Instant Messenger's Real-Time IM
http://help.aol.com/help/microsites/microsite.do?cmd=displayKC&externalId=223568 [aol.com]
However, we all wanted an open standard, that works on unmodified Jabber/XMPP, and that is how XEP-0301 got developed.

Re:Why? (1)

ErikZ (55491) | more than 2 years ago | (#36689354)

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 (5, Informative)

mdrejhon (203654) | more than 2 years ago | (#36689314)

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.

Back to the future (0)

Anonymous Coward | more than 2 years ago | (#36689656)

What fanfare over nothing, as post said above 1981 is reinvented. Next they will bring back the 300 BAUD modem.

Re:Back to the future (1)

mdrejhon (203654) | more than 2 years ago | (#36689720)

Unfortunately, deafies are stuck with this:
http://en.wikipedia.org/wiki/TDD/TTY [wikipedia.org]
That's 45 baud.

It is feature that is partially targetted to the deaf, too. The spec introduction even explains benefits for the deaf, and is potentially a replacement for TDD/TTY over the long term.

ICQ did this at one point (1)

LS (57954) | more than 2 years ago | (#36690182)

does no one remember?

Re:ICQ did this at one point (1)

hitmark (640295) | more than 2 years ago | (#36692170)

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:ICQ did this at one point (1)

Dan541 (1032000) | more than 2 years ago | (#36692512)

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

this reminds me of how texting worked in There.com (1)

cslewis2007 (1120851) | more than 2 years ago | (#36690396)

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.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...