On Wed, Mar 2, 2011 at 2:22 PM, Mark Rejhon <[email protected]> wrote: > Thank you for your comments! I will address the most important one > first, because it deserves its own reply: > >> This is somewhat counter-intuitive, as if network latency is >> consistent, the edits will arrive at a similar sort of rate to that at >> which they were transmitted and if it's not consistent, the edits are >> unlikely to arrive in a timely manner. I have a suspicion that what's >> happening here isn't the use of the delays that make the transmission >> delays less noticeable, but rather that the act of rendering the new >> text slowly is itself masking network latency. I wonder if there's a > > That's not the issue. Our open-source software code now INCLUDE all > the following 'experimental' adjustments: > - Higher and lower intervals. > - Displaying text instantly as we received text. > - Displaying text in a time-smoothed manner. > - Delay codes (Natural Typing) > > We found that the last bullet was vastly superior to all the other > options. <snip/>
I've been convinced that this feature is of sufficient benefit to a group of the users that it's worth including (And I think this also implies sending over the transform methods, either as-specced or some other thing more advanced than <fragment>s). Referring to my other mail, I'd suggest that tier one of mandatory implementation is <fragment>-equivalent (i.e. always sending the complete text so far) and that tier 2 is everything else, including the delay codes (where tier 2 is OPTIONAL, but if you implement it you MUST implement all of it)). /K
