On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström < [email protected]> wrote:
> On 2012-07-23 21:17, Mark Rejhon wrote: > > Example 1: I suggest that this could be better demonstrated by not >> cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or >> something like that. Experience and/or cynicism say that implementers >> are quite likely to look at the examples, ignore the text, and >> misunderstand what's going on if the examples provide convenient >> semantics not required by the protocol. > > > [Comment] > I don't like this change. Are you sure? > In some earlier messages, I mentioned that word transmission is **greatly > preferable* *to broken-word transmission. > Also, if an implementer misunderstands, this detail is a more harmless > misunderstanding than broken-word transmission. > > There are other examples in the spec. > Comments welcome from people other than Kevin and Gunnar -- I need more > comments because I have comments that they prefer this Introduction, so I > need to reconcile conflicting advice about the Introductory example. > XEP-0301 permits you to transmit real-time text any way you want: > character-at-a-time, word-at-a-time, word bursts, original typing > intervals, time-smoothed, etc. The Introductory Example is unable to > demonstrate all of the possible methods. IMHO, I chose the 'safest' > introductory example. > > Again, word transmission is greatly preferable over broken-word > transmission. (There's been arguments in some accessibility organizations > in some countries, some say they prefer keypress intervals, some prefer > word transmission instead of keypresses, etc.) I am talking to a guy from > a telco in UK, and he informed me of a political debate. > > Can at least a few more "outsiders" comment on this change, please? > Thanks :-) > > I have also noticed occasional theoretical discussions about word > transmission instead of real-time text. But that just introduces delays. > Long words can take long time to type on small devices, and many times you > have benefit of seeing the word created in real-time so that you can keep > your mind in sync with the sender. > We discussed this before. If a word takes longer than usual to type, you just simply transmit whatever the word is so far. It will cause occasional broken words for those times that people take a long time to compose a word. But that's OK. Even if it could be mentioned somewhere, the spec is about real-time text, > and the first example, showing the very basic features shall also show a > realistic example of transmitting real-time text. Not word-by-word. > I disagree. There are implementers demanding word transmission. Your edit is rejected unless there's lots of demand (i.e. 5 people publicly agreeing with you with no further disagreements in the mailing list) Word-by-word also have the risk of delaying the last typed word from being > transmitted. It must have some inactivity timeout and transmit whatever is > typed if the user just stops typing at the end of a word without any space > or punctuation mark. In order to not interfere with slow typing, a timeout > should likely be in the order of 7 seconds. That is an unfortunate extra > delay in these circumstances. > That is not a problem, if you have a time limit for word composition (i.e. 1 second transmission interval, and reset the transmission interval everytime you hit the spacebar. So that words come out very quickly, with no delays more than 1 second) Please accept the proposals for the first example being a real-time text > example. > I need comments from several people. There are people (some of Darren Sturman's colleagues) who would disagree with you. Thank you, Mark Rejhon
