On Wed, Mar 2, 2011 at 9:45 AM, Kevin Smith <[email protected]> wrote: > 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)).
Excellent idea. In fact, I used a tier-based system with 4 tiers. But I decided not to include the tiers in the specification because I felt it complicated things. Perhaps if we simplify it down to 2 tiers, it would be more acceptable. How does this compromise sound: TIER 1: Standard Insert/Delete/Backspace/Reset TIER 2: High-def Delay Codes/Cursor Codes Clients that support only TIER 1 can safely ignore TIER 2 codes, and still show the real time text properly. However, TIER 2 only provides the high-def experience. As my earlier source-code snippet shows, using a serial edit code technique isn't THAT complex to program.
