[Standards] XEP-0301 0.5 comments [Sections 1 through 5]

Mark Rejhon 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.
>
>
>  [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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120723/445abdfb/attachment.html>


More information about the Standards mailing list