On Wed, Mar 2, 2011 at 5:42 PM, Mark Rejhon <[email protected]> wrote: >> 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.
Ok. I can't imagine writing an essay into my IM client, but maybe I'm strange :) > 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. Well, dropping messages without sending an error is a bug, and 198 eliminates most of this, but ok - I'll mostly buy this. >>> - 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 I don't think this is either here or there at this point, but that's still a client rendering issue - clients can choose to render these changes however they want, and bright pink in size 72 Comic Sans is an option if they want to draw attention to this. I'll buy the cursor movement as well, though, in the two-tier model. >> 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. Thanks. >> 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. This is unfortunate - XMPP mandates a minimum maximum stanza size of 10,000 bytes (it may be larger in deployments, but not smaller), and a sever MUST return an error if this is reached. > - 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. I don't think (until now) that anyone has proposed a solution that didn't allow editing. > - Transform system: It will make Tier 1 compatible with receiving Tier > 2 communications, simply by ignoring the Tier 2 specific transforms > (edit codes). It looks like this is probably what's needed. /K
