Re: [rtcweb] Text communication in RTCWEB sessions

[Mark Rejhon <[e-mail]>]

On Tue, Dec 4, 2012 at 5:25 PM, Matthew Kaufman
<[e-mail]> wrote:
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Gunnar Hellström
>> I think there are a lot of good reasoning in you entry.
>> A Real-time text UI can be quite tricky and quite processor-consuming.
>> Imagine two rapid typers, typing along with over 10 characters per second,
>> one local and one remote typing simultaneously with a UI showing  their
>> entries building up in the real-time text preview style, as traditional chat but
>> with the last entries being real-time entries continuously building up by
>> entered text. It might be heavy for JS to recalculate and display the text area
>> in such conditions.

I should note that this isn't true anymore for modern optimized
browsers, especially on GPU accelerated platforms.  They are
surprisingly efficient, thanks to nearly two decades of browser wars.
 I'm able to update text inside a fixed-size <div></div> using
JavaScript well north of tens or hundreds of thousand times a second
in desktop browser programming, the optimizations in browsers really
show.

My preference: I'd say let rtcweb provide simple text receive/delivery
API's (bare simple minimum to meet legislative requirements), and let
JavaScript provide presentation -- it's just one line of text, such as
divTag.InnerHTML = "hello, world";
It's high-performance nowadays in modern, optimized browsers,
especially when using fixed CSS bounding boxes (to prevent text reflow
overheads).  Just let the web developer worry about presentation of
real-time text, IMHO.

It simplifies things, it keeps webrtc to just the details and API level stuff.
No need to complicate things and bring W3C stuff into play for RTT.

Mark Rejhon
Author of XEP-0301 - XMPP Real-Time Text