Slashdot Mirror

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

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

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

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

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

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

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

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

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

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

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

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

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

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

You know, I found myself marveling at the quality of 3d graphics that can be done on today's hardware. I remember my Super Nintendo, and how great the graphics on it were. Then I remember buying a 3d accelerator card, a Voodoo Blaster Banshee (16MB PCI) and playing OpenGL quake2 for hours. I swore to myself, "It'll never get any better then this" Boy was I wrong. I can remember a dozen games that wowed me at the time, but are now totally unimpressive. That is the nature of computer generated graphics. As computers and their addin cards get faster, we can push more polygons, use higher resolution textures, and play with complicated lighting and surface manipulation in a way that no one was able to before.
Yea, those screenshots are impressive. So what if they won't run on consumer grade stuff yet? Give it a year or two and we'll be looking back at Doom3 and wondering what was so impressive.

Just some more FUD from Microsoft. Not that I actually hate all their products, but this is getting ricidulous...

I know of a few companies that use GPL open source software with LGPL-compliant plug-in API's, allowing them to keep the plug-ins proprietary while keeping the codebase open-source. Some of these companies are actually earning good money.

The most familiar example is open-source Mozilla (aka Netscape) with proprietary plug-ins such as Shockwave Flash. Also, designing proprietary software running on top of an open-source operating system can produce revenues. For example, the TiVo personal video recorder which runs Linux.

This type of plug-in technique has already been applied to other software.

Thanks,
Mark Rejhon
http://www.marky.com