On 2013-07-07 19:50, Mark Rejhon wrote:
Regarding XEP-0301 --
http://www.xmpp.org/extensions/xep-0301.html
Totally agree with the vast majority of Gunnar's answers. Just some
very minor tweaks needed.
On Sun, Jul 7, 2013 at 1:31 PM, Gunnar Hellstrom
<gunnar.hellst...@omnitor.se <mailto:gunnar.hellst...@omnitor.se>> wrote:
ADD just before table:
For consistency, the text may need to be added afterwards the table
(other parts of XEP-0301 put such table-describing text afterwards)
No problem, just make sure that the reader sees it before starting to
wonder why the seq are not in sequence in this example.
COMMENT #4
4.7 "Alternatively, recipient clients MAY keep track of separate
real-time messages
per full JID <localp...@domain.tld/resource>
<mailto:localp...@domain.tld/resource> and/or per <thread/> (Best
Practices for Message Threads [9])."
I think that some of the earlier instructions will be incompatible
with having multiple RTT messages per full-JID.
It would be worth someone else checking.
ANSWER #4
The sentence may be confusing, it is only when multiple threads
are used that multiple real-time messages
per full JID are needed.
CHANGE: "Alternatively, recipient clients MAY keep track of
separate real-time messages
per full JID <localp...@domain.tld/resource>
<mailto:localp...@domain.tld/resource> and/or per <thread/> (Best
Practices for Message Threads [9])."
INTO: "Alternatively, recipient clients MAY keep track of one
real-time message per full JID <localp...@domain.tld/resource>
<mailto:localp...@domain.tld/resource> or
one per full JID and thread if threads are used. See (Best
Practices for Message Threads [9])."
Let's discuss this a bit further with Kevin:
This type of wording change may not be sufficient.
There are these theoretical situations:
1. bare JID handling, ignoring <thread/> (execting 4.7 out-of-sync
handling on any collisions)
2. bare JID handling, interpreting <thread/> (execting 4.7
out-of-sync handling on conflicting full JID's)
3. full JID handling, ignoring <thread/> (execting 4.7
out-of-sync handling on conflicting <threads/>)
4. full JID handling, separate <thread/>
XEP-0301 would work fine with all the above scenarios. The user
experience would vary, but none of the scenarios would make XEP-0301
unusuable because, in principle, there's typically only one typist
coming from bare JID. The major usability divergences do begins to
occur when multiple typists start to use the same account (e.g. a wife
and a spouse sharing the same Jabber login). In this event, the
out-of-sync handling behaviour differences become apparent (Simple
worst case scenario: Thrashing of real-time text from one buffer to
the other buffer in a once-every-10-second cycle, in the rare
situation of simultaneous typists. But when hitting Enter, the two
separate messages will still successfully be delivered)
Now, as both me and Chris has expressed that we should leave it to the
implementer to decide how it handled -- e.g. decide on what handling
to do that allows simplification of implementation to just
"one-real-time-buffer-per-chat" -- then I would prefer it that way, as
typical scenario (>99% of use cases) is one active typist per bare JID
(e.g. simply switching between devices) and all 1/2/3/4 works just
fine in that scenario in a very interoperable manner; it's mostly a UX
variance. The implementor does not have to merge window handling and
real-time-message-buffer handling, but the option is easily there, if
the implementer shall choose to do so; to simplify & improve UX.
Obviously, MUC would require support for multiple real time message
buffers per window, and thus would make it fairly easy to handle (4).
But not all clients want to support MUC, and thus would be quite a
lot simpler (multiple implementers agree with me) for such clients to
just follow (1). As a result, I want to word things in a way that
allows the implementer to decide what is easiest;
Thanks!
Mark Rejhon
My proposal did not aim at explaining lower number of real-time
messages. It aimed at what I thought was Kev's question. "having
multiple RTT messages per full-JID". So,
I inserted the explanation that it was only when there are multiple
threads per full JID that you MAY want to use one real-time message per
thread and therefore more than one for the full JID.
Kev, was that your question?
Thanks,
Gunnar
