On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström
<gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>>
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
