On Tue, Jul 10, 2012 at 2:58 AM, Gunnar Hellström < gunnar.hellst...@omnitor.se> wrote:
> Mark, > I see that you in this version have introduced a couple of "odd" real-time > text transmission strategies in sections 6.4.1 and 6.4.2, based on the > 'reset' event. > http://xmpp.org/extensions/**xep-0301.html#realtime_text_** > transmission_methodologies<http://xmpp.org/extensions/xep-0301.html#realtime_text_transmission_methodologies> Gunnar -- several are excellent suggestions. An explanation at the beginning of 6.4 The transmission strategy in 6.4.1 and 6.4.2 is not recommended for messages bigger than approximately SMS size, for mobile devices that want to write very compact & simple implementations of real-time text that does not require much processing or battery -- and they can take advantage of stream compression to eliminate the redundancy disadvantage of message resets. It was explained to me that it may actually use less bandwidth and less CPU in certain situations. Even though it means a disadvantage of losing key press intervals (the intervals demonstrated at www.realjabber.org/anim/real_time_text_demo.html) which I already mention. Stream compression compensates for the bandwidth penalty of doing repeated message resets as the method of a bare-bones implementation of XEP-0301. I also should additionally cite this as part of this paragraph, that if it's done, it's a good idea to use stream compression, if available. So when done, the strategy isn't odd anymore :-) > 3. Combine 6.4.3 and 6.4.4 to one section. 6.4.3 just describes a method > that is not recommended, and does not specify a solution, so it suits > better as introductory warning words. Use the title 6.4.3 Monitoring > message changes. delete title 6.4.4 > The only one I'd be cautious about is that 6.4.3 needs to be a distinct section; because it is less confusing to vendors trying to transmit from key press events; that way they can understand the "gotchas" of doing that (i.e. missed autospell fixes, missed copy+paste events, etc.) ... I've gotten feedback that gave an excellent rationale for 6.4.3 being part of 6.4 Thanks Mark Rejhon
