Hello, Now addressing other, less pressing items: On Wed, Mar 2, 2011 at 5:10 AM, Kevin Smith <[email protected]> wrote: >> - Technically, we could simply retransmit the whole message, which is >> also allowed by the standard (Section 3.9.3). However, this is >> inefficient for long lines of messages, > > I'm not entirely convinced about this (I think stream compression > should be smoothing out a lot of these data unless the messages get > *really* big.
- Longer messages often happen in real time text. When real time text is enabled, it was observed that some people have a tendancy to send fewer but longer messages. It was observed there was less incentive to rush and hit Enter or click Send. - Google Talk allow messages up to 2000 characters. Imagine multiple people typing long messages to you in separate windows. Now imagine it on a 'lite' 256Kbps connection or a congested cellphone network with 1 bar reception. Now additionally imagine that the server is sometimes overloaded. Now further imagine a future theoretical groupchat extension (even private extension). Clearly, it now becomes a scalability nightmare to simply retransmit the whole message. > I don't think this is true - XMPP already guarantees in-order > delivery, so this spec shouldn't have to deal with that. [snip] > I'm surprised you found missing messages a significant problem, but > maybe this is necessary. -- Lost message case #1: There were occasionally times in the last year that Google Talk servers were slow and overloaded, and approximately 1 out of 10 messages were being dropped. This can be enough to severely mangle real time editing that utilizes a transform protocol (edit codes) -- Lost message case #2: Also, when we pushed real time text to extremes (10 XMPP messages per second sustained by a 120 WPM touch typist like me), Google Talk started to occasionally drop messages. Perhaps, I suspect that it's a DoS safety mechanism being triggered by abnormally high rate of XMPP messages (message flooding protection system). -- Out of order messages: I found that out-of-order messages occasionally happened with RIM's Google Talk for BlackBerry, whenever there was a congested connection, or that both cellphones briefly lost reception. I suspect it's transcoding to a proprietary protocol, but this is a case of real life out-of-order messages. Although it's definitely possible to skip detection of these cases, and see real time text working most of the time, we shouldn't rely on that. Imagine a chat app on a cellphone in one-bar reception areas, causing enough XMPP messages to be bunched together (say, 100 XMPP messages accumulated during a brief reception outage) and then suddenly sending so many messages, it can sometimes trigger a server to start dropping messages -- Google Talk did. I saw other servers that did, too. Obviously, Google is one of the more popular XMPP systems -- something I can't overlook. I can eliminate talk about out-of-order detection after what you said. We will still need missing message detection so I think the 'seq' attribute needs to stay. >> - Cursor movements are included because it makes it much easier to >> watch the remote person edit their real time text -- otherwise, edits >> to the middle of their message sometimes went unnoticed more often by >> the recipient (and lead to more misunderstandings due to missed >> edits). > > Surely that's a client rendering issue, though? No. Imagine distracted recipients not paying attention. They look away for 1 or 2 second, and they don't notice a critical word in the middle of a 10 lines of text has changed (in a sudden single burst in a random location in the middle of the text). By using delay codes and cursor movements, there's more than 1 second of 'activity'. The sender starts moving the cursor back to the word, backspaces the word, types in a new word, and then moves the cursor back. For many average non-geek typists, that's 5 second worth of typing, possibly more. The fact that the cursor is not at the end of the text, means somebody is doing editing. The person who looks away for a second or two, is MUCH more likely to catch somebody making a real time edit. Less missed edits. Less misunderstandings. One skeptic who hated real time editing (because he missed edits), started to like it better as a result. It's part of the "high-definition" real time text experience... > No, but they're (from memory) SHOULD, which is as near as. [snip] > If these things can be safely ignored, then they should be OPTIONAL, > rather than SHOULD. There will be a dramatic reduction on the number of RFC2119 language, since there's a lot of unnecessary repetitions. I will also look into simplifying into fewer different RFC2119 words. > Certainly, if there are two different models, one easy, one hard, we > should make it as easy as possible to implement the easy one. I still > have doubts about the need for anything difficult - this is why > Council (or I, anyway) seek community feedback on the spec. I totally understand. I like the idea of a two-tier system (Tier 1 simple, Tier 2 advanced/high-def). The devil is in the details. For example, should Tier 1 be a whole-message retransmit system, a fragment-based system, or a transform system? This could generate some interesting discussion: - Whole message retransmit: See scalability problems that I explained, with Google Talk allowing 2000 character messages, and real time text conversations often causing people to hit Enter/Send less often. - Fragment system: Makes it difficult to do message editing. If we disable editing, it forces the clients 'send box' to behave differently when real time text is enabled. If you observe my animated video of real time text (already mentioned earlier), you'll see that real time text can be a bolt-on enhancement to a pre-existing user interface. - Transform system: It will make Tier 1 compatible with receiving Tier 2 communications, simply by ignoring the Tier 2 specific transforms (edit codes).
