[Standards] XEP-0301 0.5 comments [Sections 1 through 5]
markybox at gmail.com
Mon Jul 23 23:41:08 UTC 2012
On Mon, Jul 23, 2012 at 5:34 PM, Gunnar Hellström <
gunnar.hellstrom at 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.
> 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
I need comments from several people. There are people (some of Darren
Sturman's colleagues) who would disagree with you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards