On Sat, Aug 4, 2012 at 4:06 AM, Mark Rejhon <[email protected]> wrote: > Next, we use existing protocol (the way Kevin and I agreed) to allow the > user to replace the word "airlock" with "window": > > <message to='[email protected]/balcony' id='good1'> > <rtt event='reset' seq='4321' id='bad3'> But soft, what light through yonder > airlock breaks?</rtt> > </message> > > <message to='[email protected]/balcony' id='good2'> > <rtt seq='4322' id='bad3'><e p="36" n="7/></rtt> > </message> > > <message to='[email protected]/balcony' id='good3'> > <rtt seq='4323' id='bad3'><w n="300"/><t p="36">bre</t></rtt> > </message> > > <message to='[email protected]/balcony' id='good4'> > <rtt seq='4324' id='bad3'><w n="120"/><t p="39">ks</t></rtt> > </message> > > <message to='[email protected]/balcony' id='good5'> > <body>But soft, what light through yonder window breaks?</body> > <replace id='bad3' xmlns='urn:xmpp:message-correct:0'/> > </message>
[sidetrack below] (Side comment -- unrelated to the original topic matter -- but related to Paul's usage of Wait Interval elements -- <w/> used for key press intervals) -- Although valid <rtt/>, one caveat, whenever <w/> is used, I generally have one <w/> per character -- rather than one <w/> per multiple characters, but this is still allowed by the spec for optimizing bandwidth, e.g. sampling the text box via a timer, at a lower frequency than key press events / text change events. I prefer higher-precision key press intervals (I can even tell the difference between 1/100sec granularity and 1/1000sec granularity, when a key is held down). So when a key is held down, I prefer all 60 action elements per second (30 single-character Insert Text's per second and 30 Wait Intervals per second, between the Insert Text). RealJabber does it this way. But this can be quite large stanzas (approaching almost a kilobyte), though this is like "hi-fi" equivalent, in typing, to my eyes. Now, optimizing for bandwidth by using fewer Wait Interval's (e.g. one wait interval for every 2 or 3 keypresses) is allowed by section 6.1.4 "Low Bandwidth and Low-Precision Text Smoothing": Quote: "Clients can optimize for bandwidth, performance and/or screen repaints by eliminating, merging, or ignoring Element <w/> – Wait Interval selectively, especially those containing shorter intervals. " So paul's usage of Wait Interval's is allowed. Note, that I tend to prefer to have the <rtt/> fully stuffed with all wait intervals (e.g. totalling 700ms of <w/> intervals for each <rtt/> that is transmitted every 700ms seconds apart), but the trailing intervals can be omitted for convenience, at the possible cost of jerkier text playback whenever the ping varies quite a lot. Not a biggie, but a consideration. All fairly nitpicky details, that are probably best left out of the spec, but it bears worth mentioning. [/sidetrack]
